18

WhatsApp had recently announced end-to-end encryption on all communications. While that's an impressive move, I still have a big open question mark.

The articles and this white paper suggest that the public key, upon generation, gets stored on the server. When I want to speak to another person, I ask the WhatsApp server for their public key, and use that in communication. That same white paper says this about key verification:

WhatsApp users additionally have the option to verify the keys of the other users with whom they are communicating so that they are able to confirm that an unauthorized third party (or WhatsApp) has not initiated a man-in-the-middle attack. This can be done by scanning a QR code, or by comparing a 60-digit number.

Oh, that's nice, how are those things generated?

The QR code contains:

  1. A version.
  2. The user identifier for both parties.
  3. The full 32-byte public Identity Key for both parties.

When either user scans the other’s QR code, the keys are compared to ensure that what is in the QR code matches the Identity Key as retrieved from the server.

But... those are all details that the server knows, and requires nothing special from the other person (it doesn't mention the QR being signed). How about the 60 digit number?

The 60-digit number is computed by concatenating the two 30-digit numeric fingerprints for each user’s Identity Key. To calculate a 30-digit numeric fingerprint:

  1. Iteratively SHA-512 hash the public Identity Key and user identifier 5200 times.
  2. Take the first 30 bytes of the final hash output.
  3. Split the 30-byte result into six 5-byte chunks.
  4. Convert each 5-byte chunk into 5 digits by interpreting each 5-byte chunk as a big-endian unsigned integer and reducing it modulo 100000.
  5. Concatenate the six groups of five digits into thirty digits.

Again, those are details the server can easily calculate and present to me as valid verification data.

Am I misunderstanding this, or is there no real way of verifying that the public key I'm talking to belongs to the person I think it does?

Improve this question
6
  • 2
    TL;DR: You download and cache the public key and a MitM attack requires the attacker to swap out public keys. So he can re-encrypt traffic but then the public key of the other party won't match the one you see which you can detect by verifying the (QR) code in person.
    – SEJPM
    Commented Apr 6, 2016 at 0:26
  • I don't understand how your objections are a problem. Can you outline the attack scenario you're concerned about?
    – Volker
    Commented Apr 7, 2016 at 8:43
  • @Volker I'm not sure myself, I'm a security enthusiast, not an expert. But isn't it bad that you can't reliably verify the key's correctness?
    – Madara's Ghost
    Commented Apr 7, 2016 at 10:46
  • @MadaraUchiha: What do you mean, you can't? You meet your friend and compare the security codes. If they match, you know you're actually communicating with your friend and not a man in the middle. If they don't, someone is evesdropping. What would a potential attack look like here?
    – Volker
    Commented Apr 7, 2016 at 11:32
  • @Volker But you are comparing public keys, keys that could originate from the server, and not from your friend's device.
    – Madara's Ghost
    Commented Apr 7, 2016 at 11:35

1 Answer 1

Reset to default
4

Both the QR code and the 60 digit number need to be verified "out of band", for example:

  • Saying the number out loud in a telephone call
  • Meeting in person and scanning the QR code directly from the other device
Improve this answer
2
  • 1
    All of this is rendered useless when closed-source WhatsApp just copies your private keys to their server. =o)
    – kittycat
    Commented Apr 6, 2016 at 7:32
  • 1
    Yes, but the QR can be generated entirely from server-known information, you can't trust the QR being generated from the locally generated public key alone.
    – Madara's Ghost
    Commented Apr 6, 2016 at 12:19

You must log in to answer this question.

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