14

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Private Guy
  • 141
  • 1
  • 3
  • 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 '22 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 '22 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 '22 at 07:26
  • If it's certainty you want then the same way an attacker would discover it: reverse engineering. – President James K. Polk Jul 29 '22 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 '22 at 11:12

4 Answers4

21

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 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 '22 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 '22 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. – Steffen Ullrich Jul 29 '22 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 '22 at 23:19
  • @SteffenUllrich I agree with you that it's best to wrap up the crypto. But what I am saying is that if you upload plaintext with a key in the http header inside of mTLS, or perform a get request with a key in the header; you actually have no idea if it's stored encrypted or not. – Rob Jul 30 '22 at 00:04
  • 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 '22 at 00:07
  • @Rob: Right, adequate client side encryption *before* transport mitigates the risk of inadequate server side encryption at rest. Not only that, it also prevents the server any access to the plain text before doing the server side encryption at rest, i.e. there is much less trust needed into implementation and operators of the server system. – Steffen Ullrich Jul 30 '22 at 05:20
  • Is there any (real or even just theoretical) decentralised messaging app whose source code could be public and auditable? Could it be possible? – stevec Jul 30 '22 at 13:47
  • @stevec: off-topic. But it possible, since with good crypto only the keys are secret, not the algorithms. Also, just [use a search engine](https://www.google.com/search?q=open+source+decentralized+messaging) and you will find. – Steffen Ullrich Jul 30 '22 at 14:19
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.

user10216038
  • 7,552
  • 2
  • 16
  • 19
  • 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 '22 at 07: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 '22 at 08:32
  • fwiw a good indicator is that it's all open-source and on github (: – user1067003 Jul 29 '22 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.

Grooke
  • 248
  • 1
  • 6
  • 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. – multithr3at3d Jul 28 '22 at 16:59
  • 3
    The problem with inspecting the traffic is that "look encrypted" and "look compressed" are nearly indistinguishable. – Mark Jul 29 '22 at 03: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](https://security.stackexchange.com/q/263582/118457) – ilkkachu Jul 29 '22 at 11:57
-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).

Mr. Engineer
  • 684
  • 1
  • 4
  • 10
  • This is just a repeat of Grooke's answer – schroeder Jul 30 '22 at 17:24
  • 1
    You are right, I provided more details about how he could do it, thought. – Mr. Engineer Jul 30 '22 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 '22 at 09: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. – Mr. Engineer Aug 01 '22 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 02 '22 at 13:59