¿Por qué iterar 5200 veces cuando se calculan los números de seguridad en Signal?

El comentario no se explica muy bien, pero creo que he determinado las matemáticas detrás de él. El número de seguridad es de 60 dígitos de la base 10, pero se crea en dos mitades de 30 dígitos: una basada en su número de teléfono y clave pública, y otra basada en el número de teléfono y clave pública de la persona con la que está hablando.

Suponiendo que un alto valor de entropía se convierta en un número de 30 dígitos sin pérdida innecesaria de entropía, contendrá log ₂ (10 ³⁰ ) ≈ 99.66 bits de entropía, equivale a 99.66 "bits de seguridad" (lo que significa que un atacante tendría una probabilidad del 50% de hacer coincidir ese número de seguridad después de 2 hashes ^99.66 / 2 = 2 ^98.66 ). Iterar muchas veces aumenta los bits de seguridad (ya que aumenta el número de operaciones hash para cada intento que realiza el atacante):

log ₂ (10 ³⁰ × 1024) ≈ 109.66

log ₂ (10 ³⁰ × 1400) ≈ 110.11

log ₂ (10 ³⁰ × 5200) ≈ 112.00

Esto es para la cantidad de hash que un atacante tendría que realizar para coincidir con un número de seguridad específico, pero si el atacante deseaba poder leer los mensajes que les envías, tendrían que hacerlo. Conozca la clave privada que coincide con la clave pública que usaron en el hash. Generar pares de llaves RSA es computacionalmente costoso, pero ECC es mucho más rápido. Si la generación de par de llaves es lo suficientemente rápida, tiene sentido repetir el hash para aumentar el límite inferior de un ataque en un número de seguridad.

El número de seguridad es una derivación del identificador estable y la clave pública de un usuario. Los números de seguridad se calculan para ambas personas en una conversación.

El código realmente importante es este 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);
      }

Lo que está sucediendo es que estamos tomando la versión de huella digital, la clave pública y el identificador estable como entradas de inicio y hashing que una vez con SHA-512. La segunda iteración define la clave pública del hash que acabamos de producir, y luego la hace una segunda vez.

Este proceso de agregar la clave pública y repetir el hash continúa para el número de iteraciones indicadas.

¿Por qué necesitamos hacer más iteraciones que en el pasado?

Esto se debe a un problema fundamental si hash. ¿Cuál es la posibilidad de colisiones hash.

Digamos que soy un atacante (Eve). Alice quiere hablar con Bob, así que Signal envía su clave pública a Bob, pero Eve intercepta la clave pública y la sustituye por la suya. Normalmente hay una indicación de que la clave cambió, y el número de seguridad cambia.

Si Eve tenía suficientes recursos, podría construir una clave pública que coincidiera con el número de seguridad. Para combatir esta amenaza, lo hacemos para que Eve tenga que encontrar una colisión que ocurra después de 5200 rondas de hash, con la adición de esa misma clave en cada ronda.

Esto se vuelve inviable computacionalmente ya que cada ronda de hashing hace que encontrar una colisión sea más costoso computacionalmente. El número de iteraciones actualmente seleccionadas generalmente se calcula sobre el tiempo que tomaría un ataque de este estilo en función de los recursos de la amenaza percibida.

No puedo encontrar ningún cálculo de Signal sobre por qué eligieron 5200.