13

There are many new messaging apps that claim to be the most secure.

How can we be certain if there is actual encryption and what type of encryption?

Molly, signal, WhatsApp, briar, wire, telegram, Threema.

5
  • 11
    Not criticizing your (IMO excellent) question, but since you mention that apps claim to be "the most secure", it's important to note that an app could potentially use "good" encryption and yet not be secure. For example, they could have implemented algorithms perfectly, but if they get the private keys from a source that they can access freely, they could decrypt all traffic (even if no one else could). Others may be more honest but have a worse implementation, like using a less secure algorithm. Which is better is up to you and your use case, of course. Just don't assume encrypted = secure.
    – Blueriver
    Jul 28 at 18:45
  • 3
    If it's open source, you can inspect the source code. Otherwise the only way to know for sure is through penetration testing of some kind.
    – John Wu
    Jul 28 at 20:45
  • 4
    @JohnWu You would still need to make sure that the version you get from the App Store corresponds to the source code on GitHub.
    – gerrit
    Jul 29 at 7:26
  • If it's certainty you want then the same way an attacker would discover it: reverse engineering. Jul 29 at 18:38
  • In the case of apps distributed to criminals by law enforcement, the last one was according to all reports totally secure - except an unencrypted copy of each message was sent to law enforcement. And since law enforcement didn't decrypt anything, that was legal (as far as law enforcement is concerned).
    – gnasher729
    Jul 31 at 11:12

5 Answers 5

20

How can we be certain if there is an actual encryption and what type of encryption.

Unless you have access to the code and have the knowledge to analyze the specific implementation and algorithm for bugs and design errors, you can only rely on what independent and widely acknowledged experts on the topic say. Specifically you cannot rely on claims by the vendor alone, because even with best intentions there are often design errors - cryptography is very complex both in algorithms and in implementation. And while open source implementations are at least open for independent analysis, one should not rely on any claims unless such analysis is actually done by the mentioned experts.

9
  • 1
    A good example of this is AWS encryption of S3 bucket files. You can specify a crypto key. If you don't supply the expected key, you get an error. But you have absolutely no idea how AWS actually stores the files. When you think about this, the first thing that comes to mind is that you never specified a block mode. If it was stored plaintext, you would not be able to tell. You need ciphertext and decrypting it yourself to know.
    – Rob
    Jul 28 at 23:41
  • 3
    @Rob, in a service like that, having to specify things like encryption modes sounds a bit too technical to expose. Some users wouldn't know what to answer, and letting the users decide would reduce Amazon's leeway in changing the internal implementation. (when asking for just the key, they could e.g. transparently change the algorithm used at some point if that becomes necessary, up to some practical caveats of course.)
    – ilkkachu
    Jul 29 at 11:44
  • 1
    @Rob: to reiterate on the point from ilkkachu: it is much better to let real experts decide what proper cryptography is than give users the choice. Lots of bad cryptography in applications is actually caused by libraries giving too much flexibility and developers not being able to use such flexibility in the best way. Better libraries thus present only a few sane options. i.e. explicitly remove flexibility. Jul 29 at 13:20
  • 1
    Lets take AN0M for example. That app had perfect end to end encryption, and some sort of untraceable routing system, the only problem was it also sent a copy of every message to the FBI.
    – Jasen
    Jul 29 at 23:19
  • 1
    Therefore, the only way to know that something is stored encrypted is to have your client (which may have a trusted code library) upload ciphertext and never give keys to the server. That's almost never how it works; but that's the only way to know that it's encrypted.
    – Rob
    Jul 30 at 0:07
10

As others have stated, it can be difficult to impossible to validate good encryption implementations, for some definition of good.

Conversely indicators of concern can often be seen, for some definition of concern.

A key (pun intended) indicator is, "Who owns the encryption Key"? Did you create the key or was it created for you? If you didn't create the key and don't control it, then it's not yours. Even this criteria can get murky. For example, Proton Mail derives the encryption key from your password (which you created) and does not save either (they say). Decryption happens only on your client side, but it's via JavaScript they provide. Bottom line is it looks very much like your key but access to it is under the control of Proton Mail.

Another lesser indicator is many-to-many, such as a chat App. While not impossible, it's orders of magnitude more difficult to maintain end-to-end encryption for a many-to-many application. Typically these are implemented end-to-server encryption vice true end-to-end.

3
  • 1
    And of course, the larger a group is, the more likely that someone in there is a spy or a mole, making all technical solutions moot.
    – gerrit
    Jul 29 at 7:29
  • The first indicator of concern is the app being closed source. The second is the protocol being closed and app-specific.
    – fraxinus
    Jul 29 at 8:32
  • fwiw a good indicator is that it's all open-source and on github (: Jul 29 at 12:44
6

If you are only interested in finding if there is some form encryption, you can simply dump the traffic from the app and look at it to see if the contents are encrypted or not following the specs provided by the app (e.g. Telegram or Signal).

In many encryption systems, the algorithm used is actually easy to find so the recipient knows what to use. For example, GPG uses an OpenPGP Symmetric-Key Encrypted Session Key Packet as explained in this question: https://crypto.stackexchange.com/questions/74465/how-does-gpg-know-what-cipher-algorithm-is-needed-for-decryption. The information you're looking for may be simply present in the traffic from the app.

Of course as mentioned by @Steffen Ullrich, this doesn't mean that the algorithm is correctly implemented.

3
  • 4
    Also, there is a key distinction between encrypting messages between client and server vs. true end-to-end encryption, and looking at the traffic would only show the former unless you looked inside. Jul 28 at 16:59
  • 3
    The problem with inspecting the traffic is that "look encrypted" and "look compressed" are nearly indistinguishable.
    – Mark
    Jul 29 at 3:07
  • 1
    I would say no, you can't just look. If you look and find something that matches a well-documented format (like OpenPGP), and you know the keys, then you can try to decrypt with an independent implementation. Otherwise you're pretty much limited to "looks random" vs. "clearly plaintext", but that random-looking data could just be scrambled with a fixed (keyless) process, or encrypted with a improperly generated key. Consider e.g. the Q Is a sha256 hash of a unix timestamp a strong password
    – ilkkachu
    Jul 29 at 11:57
-1

You can check source code to knew app does encryption and have some ideas if it's any good at all. Telegram's client is open-source (server isn't).

-1

You can connect your phone and computer to same WiFi network and use network traffic analyzing tools such as Wireshark to determine whether or not the packets are encrypted when you send the message, but obviously this will not tell you much about actual implementation (cipher, key exchange etc.). Like others have mentioned, your best bet is to use open-source app which has been verified by experts, or app that is known to be very difficult to break because it has been tried before by experts (eg. Telegram).

5
  • This is just a repeat of Grooke's answer
    – schroeder
    Jul 30 at 17:24
  • 1
    You are right, I provided more details about how he could do it, thought. Jul 30 at 17:41
  • 1
    I call this the "encryption smoke test", you see it applied to a lot of homegrown "encryption" on Stack Overflow: "but the output doesn't look anything like the input, so it must be secure, right?".
    – CodeCaster
    Jul 31 at 9:18
  • @CodeCaster Well generally weak ciphers are not really a problem today, we have AES and elliptic curves and built-in APIs that make their usage easy. The problems are usually related to authentication (eg. who gets to use the keys). But like I said some software is considered secure because no one has been able to break it, I guess that's enough for most people. Aug 1 at 10:21
  • @Mr.Engineer the samples I'm taking about don't use well known or modern ciphers, they roll their own or use code that's been on the web for twenty years.
    – CodeCaster
    Aug 2 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.