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?

  • 40
    Why do you want to protect a Public key? It's meant to be public.
    – schroeder
    Commented Oct 30, 2020 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
    Commented Oct 30, 2020 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
    Commented Oct 30, 2020 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
    Commented Oct 30, 2020 at 23:39
  • 3
    "WhatsApp says it is end-to-end encrypted" Do you trust them? That may influence your answer.
    – Mast
    Commented Nov 2, 2020 at 14:59

3 Answers 3


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.

  • 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? Commented Oct 30, 2020 at 22:34
  • 8
    @henning -- reinstate Monica See How to securely send private keys. It's not a good design if you have to share your private key.
    – defalt
    Commented Oct 31, 2020 at 4: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
    Commented Oct 31, 2020 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
    Commented Oct 31, 2020 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. Commented Dec 9, 2020 at 11:42

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?


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.

  • 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
    Commented Oct 30, 2020 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
    Commented Nov 2, 2020 at 8:28
  • May be worth clarifying that you suggest generating a new keypair.
    – Phil Frost
    Commented Nov 2, 2020 at 20:48
  • 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
    Commented Nov 3, 2020 at 15:18
  • 1
    @a3y3 that's what certificates and CA are for
    – Oliver
    Commented Dec 18, 2020 at 3:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .