12

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?

  • 32
    Why do you want to protect a Public key? It's meant to be public. – schroeder Oct 30 at 11:25
  • 42
    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 at 12:58
  • 5
    @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 at 22:17
  • 3
    @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 at 23:39
  • 1
    "WhatsApp says it is end-to-end encrypted" Do you trust them? That may influence your answer. – Mast Nov 2 at 14:59
26

E2EE doesn't protect data at rest. Unlike Signal, WhatsApp doesn't encrypt internal message database. A forensic analysis can recover deleted messages in plain text if the lock screen password is known. 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. There you have no control of how it is used by state surveillance.

Apps with accessibility permission can see the content on the screen.

Sending passwords through Signal is somewhat safer if you implicitly trust the security of the device. Signal encrypts the message database with database encryption key which is itself encrypted with a key stored in hardware backed keystore (android 7+). That leaves deleted messages unreadable from forensic recovery even if the lockscreen password is known.

Private keys shouldn't be sent in any cases. It shouldn't be even available to you for sharing.

| improve this answer | |
  • 1
    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 -- reinstate Monica Oct 30 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 Oct 31 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 Oct 31 at 18:37
  • 1
    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 at 19:09
18

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?

| improve this answer | |
4

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.

| improve this answer | |
  • 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 at 20:16
  • 1
    @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 2 at 8:28
  • May be worth clarifying that you suggest generating a new keypair. – Phil Frost Nov 2 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 3 at 9:41
  • 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 3 at 15:18

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.