Why does the WhatsApp protocol require elaborate computation when verifying user keys?

Question

Reading through the WhatsApp protocol (PDF), I am trying to understand why the multiple hashing and other stuff done is required. According to the paper, one can compare the hash of the key material on both ends. The hash (60 bytes) is computed like this:

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.

Why is that elaborate computation needed? What if I simply do a hash of both public keys and concatenate the first 30 bytes of each key? Why would it not suffice? Is it simply to make sure to reduce collision when using only 30 bytes of each hash?

Answer 1

I agree with the comments, in that the aim of step 1 is likely to increase the cost of performing a man-in-the-middle attack. When two users want to verify their keys, the only information they rely on is that the 60-digit number derived from both their keys matches. Hence, an attacker would need to generate an expected $2 \cdot 10^{30}$ random Curve25519 keys to find two keys that generate a matching 60-digit number. Since a security level of $2^{101} \approx 2 \cdot 10^{30}$ is a little weak, additional SHA-512 operations are added to make brute force costlier (although this technically does not raise the security level, since that is generally measured in terms of the key length and not the number of operations).

Steps 2 to 5 are just to make the output human readable. See this blog post on Signal for more information on why they chose this format.

Hashing both public keys and then concatenating the first 30 bytes would also be fine, and it would in fact give you a higher security level, but then you'd end up with 60 bytes, or 120 hexadecimal characters, to compare.