# How WhatsApp users authenticate themselves in end-to-end encryption?

I read the WhatsApp Security Whitepaper and I want to know how a user A, which uses ECDH (Elliptic Curve Diffie-Hellman) to compute a master_secret, can be sure that the public keys for the recipient B used in the exchange belong to B and they have not been replaced by someone else. A uses B (public) Identity Key, Signed Pre Key and One-Time Pre Key, all stored on the server at the moment of B's registration: how can A be sure that they are actually his recipient's keys?

(ECDH is an anonymous protocol, therefore authentication must be achieved someway else)

• This has been answered over on Security.SE. – mikeazo Sep 19 '16 at 16:48
• Comments are not for extended discussion; this conversation has been moved to chat. – e-sushi Sep 19 '16 at 21:34

## 1 Answer

Basically the way WhatsApp and many other end-to-end encrypted messaging platforms work is that your device generates a public/private key pair. The public key is uploaded to the server and the private key is maintained. It is typically recommended that you do an "out-of-band" authentication of public keys with anyone you want to communicate with. This is often done by meeting in person. You can display your public key on your device, which they can see what public key they have for you (from the server) and compare. If you both see the same public key, all is well.

The reason and "out-of-band" mechanism is needed is that you cannot trust the WhatsApp channel for security yet, since security is being provided via the crypto. In theory, if you had some other trusted channel, you could use that. But if you already had a trusted channel, why use WhatsApp (or any other application)? This is why "in person" is typically the way this happens. You could do it over a phone call, or maybe even SMS, and feel sufficiently certain that correct public keys were exchanged. The beauty of how these apps work is that they allow you to decide that. That is also the disadvantage. If users don't fully understand the implications, they may be more risky than they would be otherwise.

This public/private key pair is used to sign partial ECDH key exchanges. You upload your half, signed by your private key to the server. The person who wants to communicate with you downloads one of the partial exchanges, verifies it with your public key. Completes the key exchange and uses the resulting key to encrypt the contents of the message. They then upload the other half of the key exchange, signed with their public key, and the encrypted message. Finally, you download all that info and are on your way.

• While WhatsApp is probably the best-known app for chatting on mobile phones and their improvements for security are quite good, it's worth mentioning Threema (as an example, but I don't know any others atm), where as a user you actually have an indicator about the authenticity of the other sides public key: If you just had in-band contact to someone, there is a yellow dot, and if you actually did an out-of-band verification based on QR codes, that dot becomes green. But one of the disadvantages is that (as far as a I know) the identity is bound to the phone, not the account. – tylo Sep 20 '16 at 17:58
• @JigarJoshi, yeah, basically, with DH (whether it is EC or not), I can create a bunch of public values ($g^a$) that I publish on a server. If you then want to complete the exchange, you send to me $g^b$ and use my $g^a$ to compute $g^{ab}$. Turn that into the symmetric key to encrypt the message, and send the encrypted message to me. I then look up the $a$ value, use your $g^b$ to compute $g^{ab}$, and I can decrypt your message. By signing the $g^a$ values (e.g., $g^{a_1},g^{a_2},\dots,g^{a_n}$) that I've uploaded to the server, you have assurance that they are mine. I know the private value. – mikeazo Nov 2 '16 at 11:49
• To understand how you combine two "public keys" to make a symmetric key, you have to understand Diffie-Hellman. The public keys we are talking about are very different from what you typically think of when you think about RSA, for example. Also, I provided an example in my previous comment. If you receive $g^b$ and you know $a$, you can compute $g^{ab}$. If the other party knows $b$ and is given $g^a$, they can also compute $g^{ab}$. From that shared secret value you can derive a symmetric key. – mikeazo Nov 3 '16 at 12:01
• As to your question you linked to, if Alice uploads 30 of these public keys (we'll call them pre-keys), and you want to send her 31 messages (or 31 people all want to send her messages while her phone is powered off), you are correct. They can't do it. Some implementations I've seen get around this by allowing one key to be a long-term key that can be reused, but there are some potential security issues with this. – mikeazo Nov 3 '16 at 12:04
• @JigarJoshi, I suggest you read the Wire Security Whitepaper and the SoK: Secure Messaging paper. – mikeazo Nov 3 '16 at 12:09