Tamaños de variable óptimos en el protocolo de contraseña remota segura

Question

Tamaños de variable óptimos en el protocolo de contraseña remota segura

#1 de Thomas Pornin (5 votos)

9

Estoy implementando el protocolo de contraseña remota segura:

  U = <username>              -->
                                 <--    s = <salt from passwd file>
  a = random()
  A = g^a % N                 -->
                                     v = <stored password verifier>
                                     b = random()
                              <--    B = (v + g^b) % N
  p = <raw password>
  x = SHA(s | SHA(U | ":" | p))

  S = (B - g^x) ^ (a + u * x) % N    S = (A * v^u) ^ b % N
  K = SHA_Interleave(S)              K = SHA_Interleave(S)

¿Qué tamaño de números debo configurar para todas las variables? RFC 2945 recomendó que u sea de 32 bits pero no más bajo. N es 4096 bits, g = 2.

Mi objetivo es maximizar la seguridad sin ningún gasto innecesario. ¿Qué tan grande debe ser s, a, b y u? Por último, pero no menos importante, ¿cuál es la longitud óptima para la clave de sesión K, que será utilizada por un cifrado AES?

Editar: SHA_Interleave (S) devuelve el hash SHA de cada otro byte concatenado con el hash SHA de los bytes restantes, duplicando así la longitud pf del resultado. ¿Sería suficiente SHA256? ¿Qué clave de tamaño busco para AES?

passwords authentication cryptography encryption key-exchange

pregunta jnm2 16.06.2011 - 18:09

fuente

1 respuesta

Lea otras preguntas en las etiquetas passwords authentication cryptography encryption key-exchange

¿Cuál fue el problema que tuvieron los EAU con RIM / Blackberry y cuál fue el resultado? ¿Qué países tienen acuerdos similares? ¿Es mi enrutador vulnerable si WPS está habilitado pero el código pin de WPS está deshabilitado?

score 5 · Accepted Answer

RFC 5054 tiene recomendaciones un poco más precisas. Para ser coherente, uno debe tratar de lograr un "objetivo de seguridad" determinado expresado en bits como parámetro t : a saber, que el sistema es seguro contra ataques que tienen una potencia de cálculo hasta 2 ^t operaciones elementales. El valor tradicional para t era de 80 bits, pero los avances en tecnología hacen que la potencia de cómputo disponible esté incómodamente cerca de ese límite. Dado que a los criptógrafos les encantan los poderes de 2, ahora es costumbre usar 128 bits como objetivo de seguridad. Incluso con una estimación demasiado optimista de cuánto tiempo durará la ley de Moore y lo que significa, 128 bits siguen siendo seguros durante al menos los próximos 40 o 50 años, y más allá de eso, las predicciones carecen de sentido.

Para obtener t bits de seguridad, debes tener lo siguiente:

Los elementos privados de Diffie-Hellman (aquí a y b ) deben tener un tamaño de al menos 2t bits (por lo tanto, 256 bits - eso es lo que recomienda RFC 5054, por cierto).
Las funciones hash involucradas deben tener un tamaño de salida de al menos 2t bits en general, también un tamaño de salida más corto es tolerable en muchos casos ( 2t bits de salida se trata de tener 2^t resistencia a las colisiones, pero en muchos casos las colisiones no son un problema, solo queremos 2 ^t resistencia a las imágenes previas, y para que t los bits de salida sean suficientes).
Las claves de cifrado simétricas y las claves MAC deben tener una longitud de al menos t bits (y AES puede trabajar con claves de 128 bits).
Idealmente, las sales deberían tener bits de longitud 2t para que los riesgos de colisión (dos sales idénticas para usuarios distintos) sean menores que 2 ^-t , pero puede tener sales más cortas porque el servidor puede controlar cuántos usuarios puede tener, y ciertamente será mucho más lento que 2¹²⁸ ( aquí, estamos hablando de la potencia de cálculo del servidor, no de la capacidad de cálculo del atacante).
El valor u , como desafío en línea, debe tener bits de longitud t , pero nuevamente, un valor más corto es perfectamente tolerable porque el tamaño de < em> u puede ser explotado solo en ataques en línea: con un u de 32 bits, un atacante tiene una probabilidad de 1 en 4 billones de realizar un ataque de suplantación de identidad, pero cada falla es visible al cliente y servidor. Una vez más, el servidor tendrá algunos problemas para atender miles de millones de solicitudes en poco tiempo, y ciertamente no lo hará de manera discreta. Además, el atacante también podría intentar adivinar la contraseña en sí, en las mismas condiciones de verificación en línea, por lo que no tiene sentido tener un u más largo que la entropía promedio esperada de la contraseña, y 32 bits de la entropía de la contraseña ya es una figura optimista.
n (el número primo) debe ser lo suficientemente grande como para que el módulo de logaritmo discreto n tenga dificultad al menos 2 ^t . Dicha "dificultad" es difícil de estimar, ya que funciona con costos que son de naturaleza distinta a la que se usa para, por ejemplo, romper el cifrado simétrico. Sin embargo, hay tentatives . 4096 bits son una exageración; Personalmente estaría muy feliz con 2048 bits.

SRP da como resultado un valor secreto compartido S , que luego se extiende a material de clave simétrica a través de una clave Función de derivación . SHA_Interleave() es una propuesta para dicho KDF. En RFC 5054, el KDF definido en TLS se usa en su lugar (bajo el nombre de "función pseudoaleatoria"). Para un túnel de datos adecuado, necesitará cuatro claves simétricas de 128 bits: una clave de cifrado y una clave de verificación de integridad en ambas direcciones. Si utiliza un modo combinado de encriptación e integridad, solo necesita dos claves simétricas de 128 bits (una en cada dirección).

Esto realmente parece que estás reinventando TLS con SRP, algo que es difícil de lograr en tantos niveles que realmente deberías usar el TLS original.