Why iterate 5200 times when computing Safety Numbers in Signal?

Question

Safety numbers in Signal are derived from a hash of the conversation's users public keys and their phone numbers. Safety number are used to ensure that the conversation was not MITM-ed.

When deriving safety numbers, SHA-512 iterated for 5200 times. According to the Signal safety blog, there were privacy issues re:phone numbers embedded in hashes. However this cannot be the reason, given the set of possible phone numbers is relatively small.

Comments in the source code:

The higher the iteration count, the higher the security level:

• 1024 ~ 109.7 bits
• 1400 > 110 bits
• 5200 > 112 bits

So: what is the reason for intentionally slowing down the Safety Numbers computation?

Bonus: how are roughly the security levels (1024 SHA-512 hashes ~ 109.7 bits) computed?

Answer 1

The comment isn't explained very well, but I believe I've determined the math behind it. The safety number is 60 base 10 digits, but it's created in two 30 digit halves: one based on your phone number and public key, and one based on the phone number and public key of the person you're talking to.

Assuming a high entropy value is converted into a 30 digit number without unnecessary loss of entropy, it will contain log₂(10³⁰) ≈ 99.66 bits of entropy, equating to 99.66 "bits of security" (meaning an attacker would have a 50% chance of matching that safety number after 2^99.66/2 = 2^98.66 hashes). Iterating many times increases the bits of security (since it increases the number of hash operations for each try the attacker makes):

log₂(10³⁰ × 1024) ≈ 109.66

log₂(10³⁰ × 1400) ≈ 110.11

log₂(10³⁰ × 5200) ≈ 112.00

This is for how many hashes an attacker would have to perform to match a specific security number, but if the attacker wanted to be able to read the messages you send them, they'd need to know the private key that matches the public key they used in the hash. Generating RSA keypairs is computationally expensive, but ECC is much faster. If the keypair generation is fast enough, it makes sense to iterate the hash to increase the lower bound of an attack on a safety number.

Answer 2

The safety number is a derivation of the stable identifier and the public key of a user. Safety numbers are computed for both people in a conversation.

The real important code is this snipit

byte[] publicKey = getLogicalKeyBytes(unsortedIdentityKeys);  
byte[] hash = ByteUtil.combine(ByteUtil.shortToByteArray(FINGERPRINT_VERSION), publicKey, stableIdentifier.getBytes());  

for (int i=0;i<iterations;i++) {
        digest.update(hash);
        hash = digest.digest(publicKey);
      }

What's happening in is we are taking the fingerprint version, public key, and stable identifier as starting inputs and hashing that once with SHA-512. The second iteration apends the public key to the hash we just produced, then hashes it a second time.

This process of adding the public key and repeating the hash continues for the number of indicated iterations.

Why do we need to do more iterations than the past?

This is due to a fundamental issue if hashing. Which is the possibility of hash collisions.

Let's say I'm an attacker (Eve). Alice wants to talk to Bob, so Signal sends her public key to Bob, but Eve intercepts the public key and substitutes her own. Normally there is an indication the key changed, and the Safety Number changes.

IF Eve had enough resources she could construct a public key which matched the safety number. To combat this threat we make it so that Eve would need to find a collision which occurs after 5200 rounds of hashing, with adding that same key every round.

This becomes computationally infeasible since each round of hashing makes finding a collision linearly more computationally expensive. The number of iterations currently picked usually is calculated on how long an attack of this style would take based in resources of the percieved threat.

I can't find any calculations from Signal as to specifically why they picked 5200.

Answer 3

These comments in the source code are wrong. Developer did not really understand what he wrote.

Here is his comment:

The higher the iteration count, the higher the security level

This statement is partially correct. Namely, it requires more resources for brute-forcing and makes it from this point of view more secure. But the probability of hash collisions depends solely on the size of the hash space, i.e. on the length of the hash (assuming that hashes are distributed equally). It does not depend on the number of iterations. Means, from the point of view of hash collisions it is not more secure.

A simple example. Suppose the hash consists of a single byte, i.e. 8 bits. In the reality nobody would use it because it is not secure. But lets us to easier understand what is going on. 8 bits means there are 256 different hashes. No matter how many iterations you do, 5200 or 1000000, you get in the end one of 256 hashes. What is the probability to get one of 256 values? It is 1/256.

Then why is smb. talking about 5200 iterations -> 112 bits?

Again, let's take first a hash of 8 bits = 256 different values. How many messages you need to try to get one that produces a given hash? In the worst case you need 256 calculations. Suppose now we use a hash function that uses 2 iterations of the original hash function. To brute-force it you need in the worst case again 256 iterations, each of them is x2 longer than the original. Means you need time like 512 original hashes, which is 2^9. This is equivalent to brute-forcing 2^9 values with the original hash function. If we use 8 iteration, the time needed is 256 x 8 = 2^11, it is like using the original hash function for 2^11 values, i.e. like increasing the hash length from 8 to 11 bits. For 5200 iterations it is like increasing the hash in log2(5200) ~= 12 bits.

In the OP the entropy is 99.7 bits. Brute-forcing a hash with 5200 iterations takes approximately the same time as brute-forcing a hash with 1 iteration but which is ~12 bits longer. log2(5200) ~=12.3; 99.7 + 12.3 = 112.

Once again: It is not correct to say that increasing the number of iterations equivalent is to the increasing of the hash size, or that it increases entropy. It only increases the needed CPU time. But the entropy remains the same, the probability of hash collisions remains the same.