6 min read
Ten years ago, most of us didn't even think about the security of the content we exchanged in messaging apps. Today, even the slightest security vulnerability is enough to make users of these apps revolt.
So, are messaging apps really as secure as they claim to be?
Boring background information:
Kerckhoffs's Principle: In the past, it was thought that algorithms would be secure if their business logic was hidden. However, in the 1970s, Claude Shannon pioneered Kerckhoffs's Principle, which embraced the idea of "Open algorithm, Secure data". In other words, a system's security should depend only on the secret key. The system should remain secure even if the algorithm itself is known to everyone. This idea formed the foundation of modern cryptography and eliminated the notion of "security through obscurity".
You can use this when trying to explain to your bosses at work that the code they write isn't the world's most secret code 😃
A historical mistake: Netscape used predictable information like timestamps and device-ids in the PRNG (Pseudo-Random Number Generator) numbers it produced for SSL. Moreover, it relied on keeping its business logic and compiled code secret to ensure security. Eventually, Ian Goldberg and David Wagner revealed this weakness through reverse-engineering. We can say that this security vulnerability was one of the factors that led to Netscape's downfall.
Important background information:
Forward Secrecy: Separate encryption keys are used for each communication session (with HKDF). The compromise of a current key does not compromise the security of past communications.
Deniability: Users can plausibly deny sending a particular message. Third parties cannot verify the authenticity of messages. Even if law enforcement or a court physically seizes the device of the person you've been communicating with, they cannot mathematically prove that the generated keys were produced with you. This feature is called deniability in cryptology.
Relative Importance of Server Security: When Forward Secrecy and Deniability are properly implemented, server-side security becomes secondary. Even if data is stolen from the server, user communication remains protected thanks to these features.
After these boring explanations, let's now put today's messaging applications under the microscope.
If a messaging application claims to do end-to-end (E2E) encryption, it should be able to answer the following questions:
Cryptology:
- What end-to-end encryption protocol is used? Is it Double Ratchet, or their own implementation with a simple Diffie-Hellman like Telegram?
- If ECC (Elliptic Curve Cryptography) is used, what curve is used?
- Is there a KEM (Key Encapsulation Mechanism)?
- Was the protocol developed by cryptanalysts? Or was it implemented by programmers?
- Is the same library used on all devices?
- Was the protocol developed in C? Or which language was it developed in? For example, Java's JVM nature makes it almost impossible to take precautions against side-channel attacks.
- Is Forward Secrecy supported?
- Does it provide Deniability?
- Are there mathematicians working in the team?
- Does it support PQC (Post Quantum Cryptography)?
- Is the Noise Protocol used?
Server:
- Is the server code open source?
- Can the server code be self-hosted?
- Where are the servers located?
- Have scenarios been planned for possible attacks? If registration is done with a phone number or email, what structures can protect metadata?
Client:
- Is the code open source? If the code isn't open source, are all security details provided in the Whitepaper?
- Is the app I download from the store the same as the open-source code?
- How is Login Token security ensured? If multi-device is supported, how is token security ensured between devices?
- How can I register?
If I can use it anonymously: Is there a precaution against the Birthday Paradox? - How are secret keys managed on clients' devices? Can hardware-based encryption methods be used?
Other questions:
- Does it support multi-device management? Is the Sesame protocol used?
- Does it support FIPS Standards? Has it passed the FIPS test?
- After logging in on multiple devices, what happens when a device is lost?
- Does it offer a way to verify that the person you're talking to is real?
- What happens if a user loses their secret keys? Is the other user notified about this?
- Is group messaging end-to-end encrypted? (MLS Protocol)
- Are group media messages encrypted?
- Is the group key distribution protocol secure? That is, if one of the group members is malicious, are precautions taken against this?
- Has the protocol been reviewed by independent organizations?
- Have penetration tests been conducted?
- How do they make money?
- Is user data used for monetization?
- Have threat models been generated? What precautions have been taken against these?
These questions can be multiplied, but when looking at these basic questions, Telegram, Threema, and WhatsApp are out of the question, while Signal seems to be the most suitable among them.
However, some questions come to mind about Signal:
- Why doesn't Signal push its server code like it used to?
- Why can't Signal's server code be self-hosted anymore? I'm referring to V7 and later.
- Why did WhatsApp's founder donate $50 million to Signal?
- How does Signal make money?
They themselves show a loss every year and say they keep the business going with donations. It must be true 😀 - What's the reason Amazon gave a significant discount when Signal moved its servers to Amazon?
Why are they so eager to bring peace, tranquility, and happiness to the world? 😀 - Why doesn't it respond to rumors that American courts have put Signal conversations in front of defendants?
Of course, Community Signal, which is Signal's official or unofficial channel, has answers to these questions, and I asked some of them, but I don't know, I couldn't be satisfied 😀
Conclusion:
Unfortunately, no messaging application is completely secure. The most sensible action here seems to be to live in accordance with the laws and remain an anonymous individual in the digital world.
A personal advice: don't make your own cryptology implementation.