Pregunta:
¿Es este número primo lo suficientemente grande / demasiado grande para un Diffie-Hellman para AES-256?
Stefano Palazzo
2011-07-13 12:57:52 UTC
view on stackexchange narkive permalink

Estoy usando un intercambio de claves Diffie-Hellman para cifrar datos usando AES-256. El número primo que estoy usando es el del grupo de 8192 bits especificado en RFC 3526 (página 6).

La página 7 sugiere que, con un exponente de 620 bits, es una fuerza de clave equivalente de 310 bits, por lo que es lo suficientemente grande para AES-256. También sugiere que el primo de 6144 bits con un exponente de 540 bits sería lo suficientemente bueno (270 bits).

Ahora, ambos son bastante lentos. El más grande da como resultado que el intercambio demore unos dos segundos en mi escenario.

Por lo tanto, mi pregunta:

¿Estoy siendo ridículo? ¿Debería usar un primo más pequeño, tal vez incluso AES-128 con el primo de 2048 bits y un exponente de 320 bits? ¿Quizás entendí mal algo por completo?

Para el contexto: la velocidad no es tan importante. Necesito que este cifrado sea muy fuerte durante los próximos 10 años (como máximo). Si eso lleva dos segundos, que así sea.

En caso de que importe mucho: estoy usando un estiramiento de clave salado con 2 ^ 16 iteraciones (¿suficiente?) Antes de encriptar. AES se ejecuta en modo CBC. El hash es sha512.
No estoy seguro de que pueda estar seguro de que algo sea muy fuerte durante los próximos diez años. Con la computación cuántica, podría tener un gran cambio en lo que es seguro y lo que no.
Sí, de hecho, aunque en mi escenario (completamente inventado), tener este tipo de seguridad solo significa que no tendrá que molestarse en cambiar el sistema en el corto plazo. Si una brecha comienza a parecer más probable, sería posible simplemente cambiar el sistema, simplemente muy inconveniente.
Veo. Buena suerte para ti.
@StefanoPalazzo El estiramiento de la clave y una sal son completamente innecesarios si deriva la clave de DH.Solo es importante si la clave proviene de una contraseña humana potencialmente de baja entropía y posiblemente reutilizada.En cuanto a que AES esté en modo CBC, recuerde que CBC es maleable.Realmente debe usar la autenticación con algo como HMAC si desea usar CBC de manera segura.
Tres respuestas:
Thomas Pornin
2011-07-13 16:23:37 UTC
view on stackexchange narkive permalink

AES-256 y un módulo DH de 8192 bits son exagerados. Compararlos entre sí es un ejercicio delicado que raya en lo sin sentido, ya que ambos están bastante lejos en el reino de "no puedo romperlo ahora, tampoco puedo hacerlo en 30 años". Puede echar un vistazo a este sitio para obtener información y calculadoras sobre diversas formas de estimar la fuerza relativa de los algoritmos simétricos y asimétricos.

Parámetros prácticos que se pueden recomendar ahora para una seguridad adecuada son AES-128 y un módulo principal DH de 2048 bits (con exponentes de 256 bits).

Exagerar es un término relativo, ya que depende completamente de lo que estás protegiendo. La diferencia de velocidad no es tan mala entre AES256 y su versión de 128 bits, por lo que también podría usar la mejor, por si acaso. Habiendo dicho eso, AES-128 es suficiente para cualquier cosa menos importante que la seguridad nacional.
Hola @Marcin, ¿es ese el sombrero de papel de aluminio de 2012 con malla de cuatro capas y filtrado VHF extendido? ¿Viene en azul?
@Marcin Realmente lo único tangible que hace que AES256 sea "mejor" que AES128 es el hecho de que usa algunas rondas más que pueden protegerlo de futuros criptoanálisis, no que tenga un espacio de claves más grande (aunque el espacio de claves puede ser relevante para múltiplesataques dirigidos a otros modelos de amenazas).
Andrew Anderson
2011-07-13 19:29:23 UTC
view on stackexchange narkive permalink

Sí. Es ridículo elegir AES-256 y DH de 8192 bits.

Hay varias cosas que puede que desee considerar.

  1. ¿Está protegiendo los datos empresariales? En caso afirmativo, puede estar satisfecho con AES-128 y DH de 2048 bits. La razón es simple. AES-256 tiene políticas de control de exportación y si desea empaquetar su aplicación, entonces debe usar un jar especial (si está usando JAVA), etc. Pero, puede usar AES-256. No hay problema. Además, es lento si está utilizando algo por encima de 2048 bits DH. También debe cuidar el sistema en el que se descifrarán los datos. No debería tomar demasiado tiempo. Muchas empresas de Fortune-1000 todavía usan 3DES y usted está usando AES, que es un algoritmo mucho mejor. Entonces, está seguro con AES-128 y 2048 DH

  2. ¿Está protegiendo los datos privados de un pequeño grupo cerrado? Entonces, solo necesita AES-128 y 2048 bit DH. No se necesita nada más que eso, ya que el marco de tiempo que está considerando es de solo 10 años.

Si realmente desea más seguridad y desea probarla para el futuro, entonces DH es el camino equivocado a seguir. La criptografía de clave elíptica es la más adecuada para esto. No hay muchos recursos en esta dirección. Pero definitivamente vale la pena.

En pocas palabras: el tamaño no lo es todo en criptografía. La elección correcta de los algoritmos y la implementación es lo que realmente cuenta. Continúe con AES-128 y 2048 bit DH. Es seguro.

ACTUALIZACIÓN:

@stefano - Hola, hay varias cosas que deben tenerse en cuenta ya que dijiste espionaje gubernamental en periodistas. Los gobiernos nunca nos dicen su capacidad real. Entonces, es posible que ya tengan infraestructura para crackear AES-256. La NSA no aprobará algo que esté por encima de su cabeza. Además, AES no es el nivel más alto de seguridad disponible. Forma el nivel 2 en la pila de algoritmos de la NSA si mi memoria es correcta. Pero tenemos opciones limitadas. Entonces podemos optar por AES-256 para brindar una mejor seguridad.

Para proporcionar una mayor seguridad a largo plazo, debe considerar la criptografía de clave elíptica. Es el único sistema que está disponible en público que puede realizar pruebas futuras de manera razonable. DH se puede utilizar cuando desee transferir datos entre 2 o más partes. Supongo que conoce los conceptos básicos de la criptografía de clave asimétrica y por qué necesita DH. Si está almacenando datos en su sistema y no los está transfiriendo, no hay necesidad de DH o RSA o criptografía de clave elíptica.

Además, puede utilizar una contraseña muy segura que influirá directamente en la clave seleccionada en AES a través de la sal y SHA-512, esto le proporcionará la posibilidad de cambiar el texto cifrado de vez en cuando para que una clave débil que aparezca en algún diario no afectará a sus datos cifrados. El exponente de 256 bits está bien. Pero, para su escenario actual, un exponente un poco más alto puede hacer un mejor trabajo.

¡Fantástico! En realidad, AES128 es aproximadamente el doble de rápido en comparación con 256 (en mi caso particular). Y usar un módulo de 2048 bits es lo suficientemente rápido. Esto es muy apaciguador. ¿Está de acuerdo con @Thomas en el exponente de 256 bits? Por cierto, mi modelo de amenaza es el espionaje gubernamental a periodistas, no para fotos de vacaciones. :)
Vaya, muchas gracias por tu esfuerzo. Debe incluir todos estos comentarios en su respuesta para que sean más fáciles de leer. Debería poder eliminar los comentarios (o tal vez sea en 15 repeticiones, si no, pídale a uno de los moderadores que lo haga por usted).
@Stefano - Hecho
@Stefano: el exponente de 256 bits proviene de ataques de logaritmos discretos genéricos, que funcionan con esfuerzo 2 ^ (n / 2) cuando el rango de exponentes tiene un tamaño de n bits. Entonces, 256 bits para "seguridad de 128 bits".
@Stefano: en cuanto a su modelo de amenaza, cuando su sistema sea atacado con éxito, no será a través del criptoanálisis. Un registrador de teclas, una cámara oculta discreta ... ¡y también mucho más fácil de instalar que de romper AES de 128 bits! Aunque solo sea porque ya existe tecnología para registradores de teclas o cámaras pequeñas.
-1 por esa extraña afirmación de que la NSA no aprobaría nada que "vaya por encima de su cabeza".
D.W.
2011-07-15 11:18:36 UTC
view on stackexchange narkive permalink

Sí. Tu enfoque está muy por encima. AES-128 y un grupo Diffie-Hellman de 2048 bits (con un exponente de 256 bits) es más que suficiente. Incluso con esos parámetros, es excepcionalmente poco probable que las cripto-matemáticas sean el eslabón más débil de su sistema. Es mucho más probable que su sistema se rompa al pasar por alto la criptografía, que al romper la criptografía de frente.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...