31

I am asking this because WhatsApp says it is end-to-end encrypted.

  1. Are there any problems with sending a public key through WhatsApp?

  2. There might be some objections to sending symmetric and private keys.

Under what circumstances can I send symmetric and private keys?

kelalaka
  • 5,409
  • 4
  • 24
  • 47
Olle Hudga
  • 419
  • 1
  • 3
  • 4
  • 40
    Why do you want to protect a Public key? It's meant to be public. – schroeder Oct 30 '20 at 11:25
  • 53
    `Under what circumstances can I send Symmetric and /or Private key?` If you are sending your private key, *under any circumstances*, then you are doing something wrong. – mti2935 Oct 30 '20 at 12:58
  • 9
    @schroeder _"Why do you want to protect a Public key? It's meant to be public."_ - OP might want authenticity for their public keys, which is also a form of protection. They never specified they were (just) interested in secrecy. – marcelm Oct 30 '20 at 22:17
  • 4
    @mti2935 Unless you are sending it to yourself (e.g. for backup, or just to have it available for use on multiple machines) – Bergi Oct 30 '20 at 23:39
  • This entirely depends on the severity a breach would have and your threat model. It is generally a bad thing to transport key material at all, but there might be less critical situations. You can always use another layer like PGP or passphrase encrypted archives. The same applies to phonecalls, usb sicks, SCP and other methods, they can all be fine or not strong enough. – eckes Oct 31 '20 at 21:13
  • 3
    "WhatsApp says it is end-to-end encrypted" Do you trust them? That may influence your answer. – Mast Nov 02 '20 at 14:59
  • How comfortable are you with Facebook knowing your private key? – BruceWayne Nov 02 '20 at 16:18

3 Answers3

47

E2EE doesn't protect data at rest. Unlike Signal, WhatsApp doesn't encrypt internal message database. A forensic analysis can decrypt deleted messages if Data Encryption Keys which encrypt user's and application data are compromised. It seems to be impractical but that's what spyware agencies are doing now.

According to this research paper: Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions (pdf) which is also covered by WIRED: How Law Enforcement Gets Around Your Smartphone's Encryption talks about design flaw in data encryption of android and iOS. One of its author has briefly explained it for iOS, although the method of exploitation is same for android as well.

Android and iOS keep data encryption keys in memory once a user unlocks its device first time since last reboot. This is called After First Unlock (AFU) state. Keys remain in memory even if the device is relocked again. This is intended this way to maintain user experience and to keep user focused app functional at locked screen which include messaging apps, contacts, songs, notes, reminders, etc. Most of the time your device remains in AFU state. If you reboot your device but don't unlock it yet, your device state is in Before First Unlock (BFU) state. In BFU state, user and app data are still encrypted. To decrypt them, your device prompts to unlock screen using your screen lock password which is then fed to key derivation to derive a Key Encryption Key that decrypts data encryption keys. This is why biometric to unlock screen doesn't work first time after reboot.

Once data encryption keys are extracted from memory physically that is directly tampering with SoC without disconnecting the battery or by using zero day exploits, spyware agencies can decrypt subset of the data. Keys can be per-file basis but these are derived from data encryption keys which means even if a file has been deleted, its key can be re-derived and the deleted file itself can be recovered from NAND flash.

WhatsApp daily chat backup encrypts message database with AES-GCM-256 key which is known to WhatsApp service (see How can WhatsApp restore local or Google Drive Backups?). Although, the chat backup is not possessed by WhatsApp service but Google Drive does if Google Drive backup is enabled which most users do. There you have no control of how it is used by spyware agencies.

Sending passwords through Signal is somewhat safer than WhatsApp but not entirely. Signal encrypts the message database with database encryption key which is itself encrypted with a key stored in Trusted Execution Environment (TEE) (android 7+). Its message database has page size of 4096 bytes and IV of each page is stored in page footer. Modifying an existing page such as by deleting a message changes the IV and the entire page is reencrypted using database encryption key. If the IV of that page has been changed and possibly overwritten by new IV, there's no way of recovering a deleted message.

Uninstalling Signal altogether also clears the key in TEE which makes its database encryption key undecryptable and so does its data. But the above design flaw also affects Signal's existing messages. As database encryption key must be in memory to service messages at locked screen, it can be extracted. That's how FBI might be Hacking Into Private Signal Messages On A Locked iPhone.

Also, apps with accessibility permission can see the content on your screen which is the easiest way to compromise messages if the app that you trust is actually malicious. Google and Apple are very strict about what apps on their app stores can have code to request this permission from the user.

As for private keys, I don't believe it should be even available to you for sharing.

defalt
  • 6,231
  • 2
  • 22
  • 37
  • 3
    *Private keys shouldn't be sent in any cases.* Just curious, but what if you want to decrypt some object on different devices, e.g. if you use different computers to access your emails or an encrypted repository with your passwords? – henning Oct 30 '20 at 22:34
  • 8
    @henning -- reinstate Monica See [How to securely send private keys](https://security.stackexchange.com/questions/101560/how-to-securely-send-private-keys). It's not a good design if you have to share your private key. – defalt Oct 31 '20 at 04:29
  • 3
    @henning--reinstateMonica the general best practice would have a separate private key on each device which all independently can have access, but never leave the device and can be independently revoked/rotated. – Peteris Oct 31 '20 at 18:37
  • 2
    For multi-device support, even Signalapp has to share its private Identity key with another device so I think sometimes sharing becomes unavoidable. – defalt Oct 31 '20 at 19:09
  • Given your last sentence, what’s the point of the rest of your answer? The safety of public keys is pretty unimportant, so none of these other considerations are relevant. – Konrad Rudolph Dec 09 '20 at 11:42
  • @Konrad Rudolph I didn't address concern for public key either. I've addressed concern for sending passwords which most people do through instant-messaging because they think e2ee protects them in all cases which is not the case when messages are stored in internal storage. – defalt Dec 09 '20 at 13:29
  • if a Signal message is deleted, it's not possible to recover. Is that right? – user215422 Mar 23 '21 at 18:52
  • @user215422 Yes. – defalt Mar 23 '21 at 19:02
  • @defalt Thanks. Is there any way that makes a deleted Whatsapp message unrecovarable? – user215422 Mar 23 '21 at 20:39
  • @user215422 Only if the storage is overwritten by new files. – defalt Mar 24 '21 at 04:19
  • @defalt Can cleaning Whatsapp cache be a solution? – user215422 Mar 25 '21 at 17:49
  • @user215422 No. NAND flash storages don't overwrite NAND cells frequently. They always use unused cells until there's no more empty cells to write data. Even overwritten data can be recovered by forensic experts. – defalt Mar 26 '21 at 05:34
  • @defalt Is that same for Signal Desktop? – user215422 May 04 '21 at 10:08
  • @user215422 No. Signal Desktop database is unencrypted if disk encryption is not present. – defalt May 04 '21 at 11:42
25

No, No, No!

Don't base your security on a program that is a crippled version of the Signal protocol.

  • public key

    It is public and normally one publishes it on the net and verify it with other channels like the Signal does or call your friend and use your voice! There are formal solutions for these, the Certificate authorities.

  • private key

    It is your private, keep it safe keep it's your most valuable digital secret. Hide if from all eyes all the time!

  • symmetric key

    Why do you need it to send it? They are generated for the short term and keep them safe, too.

There are cryptographically well-studied methods for this.

  • Use Diffie-Hellman Key Exchange to establish a key and

  • use HKDF to derive a key from it for authenticated encryption modes like AES256-GCM or better ChaCha20-Poly1305.

    You will get forward secrecy if you to delete the generated key and the messages after reading

    and you will get confidentiality, integrity, and authenticated encryption. What do you want, more?

kelalaka
  • 5,409
  • 4
  • 24
  • 47
8

Your public key is public. You can publish or send it without protection. Unless you have the very specific need that your identity must not be associated with your public key.

Your private (or symmetric) key is private. You should never send or transmit it. If you need to transmit it to yourself on another device, you can use the public key of the receiving device to encrypt it before sending it.

In either case, you will notice that "Whatsapp" is irrelevant to this answer. This answer applies to any communication application or protocol.

A. Hersean
  • 10,046
  • 3
  • 28
  • 42
  • 18
    "If you need to transmit it to yourself on another device, you can use your public key to encrypt it before sending it to you." This is analogous to locking the key you need inside the box you need to unlock. How is it useful? – Phil Frost Oct 30 '20 at 20:16
  • 2
    @PhilFrost Because you can safely create a (one-time) pair of keys on the receiving device, publish the public key using the protocol of your choice (for example by unsecure email or by copy-pasting on pastebin.com), then use it on the sender device to encrypt a private or symmetric key and send it safely to the receiver using the unsecure protocol of your choice. – A. Hersean Nov 02 '20 at 08:28
  • May be worth clarifying that you suggest generating a _new_ keypair. – Phil Frost Nov 02 '20 at 20:48
  • This use case is why public-key (AKA asymmetric) cryptography was invented in the first place. There is nothing special about it. It's the purpose of public-key cryptography. Replace receiver by Alice and sender by Bob, and use one's public key to share a symmetric key to protect the rest of the conversation and you've got a simplified TLS scheme (don't try this at home, TLS does far more than just that). – A. Hersean Nov 03 '20 at 09:41
  • 1
    Um, a new keypair _is_ necessary. Otherwise you run into the problem I originally pointed out: you can send yourself the encrypted private key, but you can't decrypt it, because the key you need to do so is...well, encrypted. That you are proposing encrypting the key with _a new pair_, one where the private key is already on the receiving device, is not clear from your answer, and I suggest you edit it to be more clear. – Phil Frost Nov 03 '20 at 15:18
  • Specifically, when you write "you can use your public key to encrypt it", people are assuming the public key you're talking about is the one already discussed: the one that goes with the private key being encrypted. – Phil Frost Nov 03 '20 at 15:21
  • @PhilFrost You're right, the way I wrote it was confusing. It's so obvious to me that you have to use the public key of the receiver to send it anything, that I kinda forgot in the way that I was writing about sending a private key (which should always be avoided, a private key should not exit its device). – A. Hersean Nov 03 '20 at 17:24
  • "Your public key is public. You can publish or send it without protection.". Really? What about Man in the Middle attacks? – a3y3 Dec 11 '20 at 04:00
  • @a3y3 That's the point of public keys. However, the receiver must ensure that he got the correct public key. This is why Signal use QR codes to authenticate them in person. Their authenticity is important, but they are not confidential. – A. Hersean Dec 11 '20 at 11:32
  • @A.Hersean Agreed! But if a public key is sent without protection, it can be hard to verify its authenticity. If you send me your public key, I must know with 100% certainty that it is your public key, not someone else's. – a3y3 Dec 13 '20 at 17:00
  • 1
    @a3y3 that's what certificates and CA are for – Oliver Dec 18 '20 at 03:07