In our last article, we took a look at Signal and Telegram, two giants in the encrypted communications industry, and compared some of their features as well as their security and privacy levels. Among other things, we also sort of sketched out two other messengers that are poised to become the number one in secure and private communication – Session and SimpleX.
Let’s compare these two new start-up projects. Before that, though, I want to mention that both SimpleX and Session are startups that consistently lack a number of key features that, at least from my perspective, are essential for their everyday use. So don’t take this article as some sort of ultimate judgment on both apps – rather, think of it as an even-handed recap of where both apps currently stand and what makes each of them unique.
So let’s get to it!
Session
Session is a decentralized fork of Signal from the Loki Foundation. However, unlike Signal, Session has a big privacy feature, which is just that it’s not tied to a phone number.
Instead of a phone number, the Session app will generate your own user ID, similar to what, for example, messenger Threema does.
Your ID is random (unique) and will look something like this: 05652245af9a8bfee4f5a8138fd5c……..
So all you need to do to communicate on Session is to share your ID with the contact you want to add. Or you can also choose to get a QR code after creating an account, which you can share with your friends so they can add you to their contacts. Simple.
This way of playing with IDs is in many ways reminiscent of Threema, but unlike Threema, it is not possible to associate a phone number with your account in Session, resulting in you having to exchange your Session ID through some other communication channel (e.g. the aforementioned Threema). You don’t text anyone in Session without knowing their ID.
A more interesting feature of Session is the use of blockchain. If you’re interested in the actual details of how the app uses blockchain, you can read their blog post that explains it in a relatively comprehensive manner.
We’ll talk about this feature in more detail specifically in the “A bit of tech (and blockchain)” section. Another interesting connection between Session and the world of cryptocurrencies outside of blockchain is the 12-word account backup, which is very strikingly reminiscent of a classic cryptocurrency seed. User identifiers in this case are random-looking strings of characters that represent a public key. Because of this, there is no “authentication” of users in Session – if you can write to someone and have the correct address, you can be sure that no one has given you the wrong keys.
What’s next with privacy?
Apart from that, another advantage of the Session messenger is the fact that, unlike Signal and other messengers, Session is a decentralized project that is controlled by a community of people instead of one specific entity. Additionally, Session uses the Signal protocol and, compared to Signal itself, its messages are onion routed by default.
However, while Session may seem like a better project than Signal, Session does not, for example, support group calls or even voice and video calls. Moreover, in my bubble, Session doesn’t have a very good network effect, and so far I personally don’t see the point in using it directly as a substitute for Signal. If Session wants to catch up with Signal, it still has a lot of work to do, but the project as such is developing quite fast, tweaking bugs and shortly before writing this article it also came out with a desktop application, which has been missing so far.
However, despite the Onionisation of Session Messages, the project has also suffered from a number of failures, precisely in relation to privacy. For example, the Sessionists removed perfect forward secrecy from their forked Signal protocol – removing perfect forward secrecy thus puts all your previous messages at risk of decryption after your encryption key has been compromised.
For your own security, therefore, use Signal and other protocols that provide PFS in the meantime. However, Session is still in development, fine-tuning many things, and I’m personally a big fan of it.
A bit of tech (and blockchain)
As a decentralized communications platform, Session relies on its network of Service Nodes – a decentralized network of nodes operated by the community. This decentralization is the cornerstone of Session’s architecture. But how does this relate to blockchain technology?
If you already know what blockchain is, feel free to skip this paragraph. At its core, blockchain works like a ledger of transactions. It consists of blocks, each of which contains a set of transactions, the cryptographic hash of the previous block, and also a self-reference hash. In addition, the blocks also contain the actual solution to a complex mathematical problem. The new transaction blocks are verified by “full nodes” or “masternodes” – user-controlled computers in the blockchain network. These nodes work together to determine the validity of transactions and their order in the blockchain ledger. In a truly decentralized blockchain, participation is permissionless, meaning that there is no central authority to direct the nodes’ actions.
And now the plot twist. The Oxen blockchain that Session uses has introduced a pretty unique feature – Service Nodes. Similar to full nodes or masternodes, Oxen Service Nodes perform standard tasks such as verifying new blocks and storing the blockchain. However, they go a step further by offering network services including secure routing of Session messages. Meanwhile, Session Onion routing technology ensures that no single Service Node has complete message information. Service Nodes only know the IP addresses of the preceding and following nodes in the routing chain.
The network of Service Nodes serves as the basis of a secure messaging system in Session. However, a potential problem arises here. If anyone can create a Service Node, what is to prevent a malicious entity from creating a number of malicious Service Nodes and potentially compromising the integrity of the network? In a scenario where a single attacker controls every node in the message routing chain, the anonymity of the entire Session network could be jeopardised.
This vulnerability is known as the Sybil attack and poses a real threat to most decentralized networks (including cryptocurrencies) because malicious actors can easily flood the network due to the lack of entry barriers.
Fortunately, Session has implemented a tool to address this issue.
In many decentralized networks, setting up a new node is relatively easy, which makes it vulnerable to Sybil’s attacks. In contrast, the Oxen network implements a “staking requirement”, which requires temporarily locking the Oxen cryptocurrency to start a Service Node. In return, Service Node operators receive rewards from the Oxen block, ensuring the health and growth of the network.
Only nodes meeting the $15,000 Oxen staking requirement can participate, which prevents unqualified nodes from contributing to building the blockchain or routing Session messages.
Thus, Session has followed a sort of “proof-of-stake messaging” path in network security, which, while we may not be cheering for, is certainly worth our attention at least.
Some other Session issues
Session is undoubtedly an interesting project, but it still has a lot of flaws and bugs to fix. Here is a brief summary of some of the problems I encountered while using the application:
- Delay in receiving friend requests
- The way to connect devices is not intuitive
- Sometimes when you reply from two different devices (using the same ID), the recipient gets two different conversations.
SimpleX Chat
SimpleX Chat is a very young application. This messenger has taken privacy to a level that even Session or Signal hasn’t yet reached. Simplex doesn’t even have a phone number registration, but neither does it have a random user ID. In fact, it uses the Simplex Chat protocol, which was designed to route messages without the need for user identification, making it impossible for Simplex servers to collect any metadata.
After creating a new “profile”, you simply generate a QR code to show to anyone who also has SimpleX, they read it, and you just confirm that you really want to start a new conversation with that person. Then SimpleX works just like Signal. However, there’s a lot of “magic” going on in the background, which we’ll explain briefly in the following sections of the article.
To explain – in SimpleX you can chat using text messages, send voice messages, initiate voice calls or video calls. You can send emoji, stickers, GIFs, forward images, videos and files. Tor connectivity is also available. An interesting feature is live typing, which is a feature that streams a message to the other party. And that’s just a summary of the most basic features – SimpleX offers a lot more – and of course, all of the end-to-end features mentioned above are encrypted.
In incognito mode, it’s not possible to link a single user (even by profile name) across multiple group memberships, for example. SimpleX does not use centralized servers for communication and each direction of communication can go through different relays.
If SimpleX has no user identifiers, how can it know where to deliver the messages?
For message delivery, SimpleX uses temporary anonymous paired message queue identifiers, separately for each of your connections, instead of the user IDs used by all other platforms – there are no long-term identifiers in it. You define which servers to use to receive messages, and which servers to use to send messages. Each conversation will probably use two different servers.
This design prevents leakage of user metadata at the application level. To further improve privacy and protect your IP address, you can connect to the messaging servers via Tor. User profiles, contacts, and groups are stored only on client devices; messages are sent with two-layer end-to-end encryption.
Even in the most private applications that use Tor v3 services, if you communicate with two different contacts using the same profile, it may be possible to prove that they are connected to the same person. SimpleX protects against these attacks simply and easily by having no user ID in its design. And if you use Incognito mode, you will have a different display name for each contact, preventing data sharing between them. And that’s very cool.
A bit of tech (and SMP)
SMP is a relay server that routes messages in the SimpleX network. The SimpleX application has preconfigured specific servers, but users can also host their own server.
The SMP model itself involves three key participants – the receiver, the SMP server (message broker), and the sender.
The SMP server effectively manages “simplex queues”, which serve as data records that define the communication channels between senders and receivers. Importantly, the server is not aware of the roles of the parties, since a sender in one queue may also be a receiver in another, thus preserving privacy.
Each queue record contains two unique random IDs (one for the receiver, one for the sender) along with identification keys supplied to both parties by the client. Users must use different keys for each queue to mitigate potential aggregation and analysis in the event of an SMP server compromisation.
Creating and using queues requires sending commands to the SMP server, which we will not cover in detail (you can link to them below in the “Issues” section).
Out-of-band messages play a crucial role here. They share queue information over the trusted alternative channel, provide queue URIs, establish connections, encryption schemes, and public keys for end-to-end encryption.
The simplex queue itself is a core element of the SMP protocol:
- The sender uses the queue to send messages to the server, signing them with the queue identifier and the sender’s key.
- The receiver uses the queue to retrieve messages from the server, signing with its receiver key and decrypting the messages using the negotiated key from the queue creation.
- Server involvement is limited to managing low-level simplex queues, thus maintaining a high degree of privacy and security.
This model is based on unidirectional networks, adapted for applications requiring robust information security.
Each queue is accessed through unique asymmetric key pairs, separated for sender and receiver. The private keys are held by the sender and receiver, while the server holds the associated public keys to authenticate commands via cryptographic signatures.
In a nutshell:
Messages transmitted within the queue are end-to-end encrypted, secured by a DH secret created by out-of-band messaging and SMP confirmation.
The queue is defined by a recipient identifier (RID) and a sender identifier (SID) that is unique to the server. The Sender Key (SK) is used by the server to authenticate sender commands (identified by the SID) to send messages. The Recipient Key (RK) is used by the server to authenticate the recipient’s commands (identified by the RID) to receive messages.
The protocol uses different IDs for the sender and recipient to provide additional privacy by preventing correlation of sender and recipient commands sent over the network – in the event of a compromise of the encrypted transmission, it would still be difficult to correlate senders and recipients without access to the queue records on the server.
If you want to geek out even more beyond the scope of this article, you can find a more detailed discussion of the SMP model and SimpleX queues at SimpleX GitHub itself.
Problems
Although SimpleX appears to be the perfect encrypted messenger, it has a few minor flaws. Paradoxically, if you want to start a conversation with someone you can’t meet in person, you have to use another communication tool to forward/receive a QR invitation to open a new chat. And this is the same flaw that Session has.
Unlike Signal, SimpleX also lacks the disappearing messages feature as well.
The main reason I really like Signal is its compatibility on all devices. I can use the same profile on mobile, desktop and laptop without much risk of data loss. Everything is automatically end-to-end encrypted and synchronized with each other. SimpleX doesn’t even have a Windows or Apple Mac version yet – and is therefore unusable on PCs or laptops. Maybe I’m a boomer, but personally I’m not that comfortable typing on mobiles and will gladly wait for a desktop app.
In addition, when using SimpleX, I encountered a lot of bugs related to syncing and connecting users. In order to write with a new contact, the other party has to be online and so far there’s a lot of mess; connecting (enabling a connection between you and a new contact) can take a long time and I also see as a big bug that for some reason, your messages don’t show up immediately in everyone’s groups (and neither do the ones you’re connected to).
And to add something positive to SimpleX in the end, it’s its very interesting geeky web “linux-terminal-CLI app”.
To summarize – SimpleX is a broken and messy thing, but it is very cool.
Conclusion
Both Session and SimpleX are, in short, very interesting projects and the approach to privacy of both of them is very unique and worth mentioning at least. Both applications use end-to-end encryption to protect users’ messages and do not require any personal information to register.
SimpleX Messenger, however, takes privacy to the next level by not using any user identifiers, not even random ones, making it the first identifier-free messenger I’ve encountered (and possibly the first of its kind in the world). Although Session has been on the market longer and has a much larger user base, SimpleX Messenger is gaining popularity due to its unique approach to privacy. Both apps have their strengths and weaknesses, and each of us should choose the one that best suits our individual needs. Whether for playing, experimenting, or full-fledged communication.
