Mesibo emerges as the World’s Strongest Platform for End-to-End Encryption!
Signal is a good app and was so far perceived to be the most secure and private app. However, the algorithm has never been updated, it uses relatively outdated and fixed ciphers, and most importantly, lacks man-in-the-middle protection. The new mesibo end-to-end encryption algorithm fixes these issues and also enhances the algorithm in multiple ways! This is a second in the series, a short follow-up article.
Last month we published an article describing shortcomings in the existing Signal end-to-end encryption protocol and our enhancements to it. The article was highly commended by the cryptography experts. However, the praise did not come without criticism & objections, mainly from a few Signal fans/associates. We understand that Signal is a well-known and established app, and the doubts about our claim were natural to come. We are open to technical evaluation — Signal vs mesibo (read Conclusion). Change is often difficult to accept, but it doesn’t change the fact — mesibo is the strongest end-to-end encryption protocol in the industry now, no contest!
It is worth noting, that despite being a small upcoming start-up, mesibo has done some path-breaking work in creating a comprehensive communication platform for apps to integrate real-time messaging, group messaging, calls, and group calls. mesibo has become the most sought after platform for apps for scalable communication and those with serious privacy requirements
The intent of this article is to describe the issue in simple terms. You can refer to the previous article if you need technical details. In this article, we will use mesibo open source app as an example. Despite mesibo apps being only open-source demo apps, they are a league above Signal in encryption and protecting your private data as we will describe now.
Features for End Users — Signal Vs Mesibo Apps
From the end users’ perspective, both apps offer the same features; secure end-to-end encryption, messaging, group messaging, video and voice calls, group calls with screen sharing, push notifications, etc.
However, the way mesibo implements these features and real-time communication is way faster, scalable, and modular compared to the Signal, for example, try changing the profile image on Signal Vs mesibo and see how real-time mesibo is.
A Brief Crypto Background
A quick background for those who are not familiar with cryptography to understand the issue with Signal implementation.
When Alice and Bob want to communicate securely with each other, both of them will need their own set of Private and Public Keys. As the name indicates, Private keys are strictly private and public keys can be exchanged. Alice sends her public key to Bob and Bob sends his public key to Alice. Alice now uses her private key and Bob’s public key to generate the secret key using the Diffie-Hellman calculation which will be used for encryption. Bob does the same. This secret key is further processed by Key Derivation Function (KDF). In simple terms, the KDF job is to further strengthen the shared secret key using additional inputs, generally using hashing.
Source: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
The security of the encryption is entirely dependent on how secure is this key exchange, and it is not compromised. This is where the Signal fails. For example, what happens if Eve intercepts the key exchange between Alice and Bob and replaces Alice and Bob’s keys with her keys? The signal does not offer any protection.
Hopefully, this gives you some understanding of secure communication, now let’s look into key issues.
Issue 1: Compromised Centralized Server
As we explained in the previous section, Alice and Bob need each other’s public keys to communicate. In Signal implementation, both Alice and Bob register their public key (identity key) with a server owned by Signal. When Alice needs to communicate with Bob, it needs to ask the server for Bob’s key instead of asking Bob.
What if the server under some circumstances is compromised and issues its own key to Alice instead of Bob? Alice would be under a false sense of security thinking she got the key from Bob. The communication is now compromised and the server is listening to the entire communication.
On the other hand, mesibo has entirely removed the server and made the protocol peer-to-peer. So if Alice needs to communicate with Bob, she asks Bob for his public key and not the server.
Although this alone cannot solve the man-in-the-middle issue in Signal, it significantly enhances the security of the key exchange by removing servers that can be compromised. In the case of mesibo, Alice has no fear of the server faking keys as the server is not in the picture at all.
Issue 2: Man-In-the-Middle (MITM) Attack
In a very simplistic term, a MITM attack is the equivalent of some postman opening your mail, reading it, then resealing and delivering it to you.
Signal (and WhatsApp) offer a verification screen to alert you about such an attack. If you have used Signal or WhatsApp, you may have seen these verification screens. If numbers do not match, there is someone in between.
However, have you ever wondered what are your options if the numbers do not match (verification failed)? You’d be surprised — unfortunately, you have no option but to accept the fact that someone is watching your conversation. Both Signal and WhatsApp don’t provide any corrective options nor any feature to protect you against it.
As we explained earlier, Alice and Bob exchange keys to establish encrypted communication. What if Eve comes in the middle and replaces Alice and Bob’s key with her own?
Alice now thinks that she got the key from Bob, but it’s actually the key from Eve. The same for Bob. Now Eve can decrypt and listen to messages from Alice and Bob, re-encrypts, and sends them to each other, just like the postman in the example above.
Unfortunately, MITM is not an easy problem to solve, however, the way Signal and WhatsApp completely ignored, is unfortunate.
Eliminating Man-in-the-Middle — the mesibo way
mesibo provdes three methods to detect and eliminate man-in-the-middle issue.
- Password
- Out-of-band Certificate Exchange
- Out-of-band DH (not discussed here, refer to the previous article for details)
Password
As explained in the background section above, Alice and Bob exchanges key to generate the encryption key and then use KDF. In addition, now Alice and Bob will also use a common password that will be also feed to KDF to generate entirely different encryption keys. Due to the hashing nature of KDF, even one character password can change the entire output. So even if Eve tries to intercept the communication by faking keys, Eve will not be able to decrypt the communication since the encryption keys are now hashed using a password.
This elegant but incredible algorithm provides so compelling protection against MITM attacks that even a powerful organization will have a hard time breaking it. Below is the screenshot from the mesibo app.
Out-of-band Certificate Exchange
Unlike Signal, mesibo does not store identity public keys on the server but they are exchanged between both the parties during the early key negotiation. In addition to in-band key exchange, mesibo also allows parties to export certificates or use their own certificate and then exchange them out-of-band (say using email or other means). This completely removes mesibo from any key exchange. Any attempt to eavesdrop will fail without access to the right identity key.
This method is equally powerful as the password method and once deployed, man-in-the-middle will be completely eliminated.
Issue 3: Outdated Ciphers
As mentioned in the previous article, another reservation against using Signal implementation was the choice of fixed AEC-CBC + HMAC-SHA2 cipher (which is surprising). The AES-CBC is known to be vulnerable to various timing and padding attacks, and while it’s difficult to exploit those attacks in E2EE mode where the encryption key is changing for every message, there are better-authenticated ciphers available, and hence no valid reasons not to use them. By default, mesibo uses CTR-based AEAD ( (authenticated encryption with associated data) ciphers — AES-GCM and Chacha20-Poly1305.
mesibo also uses multi-cipher multi-key mode and implements cipher negotiation across devices. The multi cipher multi-key mode allows mesibo to change the cipher on-the-fly to make it further difficult to guess the cipher and multiple keys makes it even more difficult. mesibo provides API where app developers can select multiple ciphers and preferred ciphers.
Issue 4: Privacy of User Data
Privacy is another issue. Even if we put aside who has stronger encryption aside, not everything is end-to-end encrypted in Signal and WhatsApp, for example, your phone number, your contacts, groups you belong to, and a lot more, which reveals not only with whom you are communicating but also other sellable business data — your interests, who is your doctor, whom you bought insurance from, where do you service your car, and a lot more. So privacy is your reason to use them, it’s NOT as private as perceived.
mesibo does not require phone numbers, you can use any random strings to make your mesibo-based apps. Although the mesibo demo app uses phone numbers, they are only for demos. Also, mesibo allows you to download the entire platform and run it in your data center with your database, hence the entire data is in your control.
Conclusion and Invite to Validate Our Claim
The goal of this article is not to discourage you from using Signal, it’s a good app as long as you are aware of its limitations and know of better options. We hope we could convey that.
However, it is easy to see now why mesibo is now the strongest of all the end-to-end encryption protocols. It is worth noting that the mesibo is not a retail app, but it’s a platform used by thousands of apps to add messaging, calls, and conferencing to their apps, all these apps will have the stronger end-to-end encryption compared to Signal or WhatsApp.
If you are a developer, we invite you to try the mesibo end-to-end encryption algorithm and verify our claims. mesibo provides plenty of open-source code and tutorials to make it easy for you to evaluate mesibo and our claim.
We look forward to your feedback!