RSA advierte desarrolladores no utilizar productos de RSAEn las noticias de hoy de lo extraño, RSA (una división de EMC ) ha recomendado que los desarrolladores de renunciar al uso de la Dual_EC_DRBG generador de números aleatorios ( supuestamente) ' backdoored ' - que pasa a ser el predeterminado en Bsafe conjunto de herramientas de cifrado de RSA . Youch .
En el caso que se está perdiendo la historia aquí , Dual_EC_DRBG ( que escribí ayer) es el generador de números aleatorios votado muy probablemente a ser backdoored por la NSA. La historia aquí es que - a pesar de muchas preocupaciones válidas sobre este generador - RSA fue adelante y lo convirtió en el generador por defecto utilizado para todos criptografía en la biblioteca de criptografía de buque insignia. Las implicaciones para los productos de RSA y RSA- basada son asombrosas. En el peor de los casos una modestia mal pero no por ello peor de los casos , la NSA puede ser capaz de interceptar las conexiones SSL / TLS hechas por productos implementados con Bsafe .
Así que ¿por qué elegir RSA Dual_EC como predeterminado ? Me has pillado . No sólo es Dual_EC hilarante lento - que tiene implicaciones de rendimiento reales - que ha demostrado ser un generador de números aleatorios mal simplemente todo el camino de vuelta en 2006 . Para el año 2007 , cuando Shumow Ferguson y plantearon la posibilidad de una puerta trasera en el pliego de condiciones , no criptógrafo sensato acercarse a la cosa.
Y el asesino es que RSA emplea un número de muy distinguidos criptógrafos ! Es poco probable que todos ellos echarían de menos las noticias sobre Dual_EC .
Sólo podemos especular sobre el pasado. Pero aquí en el presente llegamos a ver de RSA CTO Sam Curry defender públicamente opciones de RSA . En cierto modo me siento mal por el chico . Pero vamos a hacer burla de él de todos modos .
Voy a tomar su línea de declaración de línea (Sam es la negrita) :
" Un montón de otras funciones criptográficas ( PBKDF2 , bcrypt , scrypt ) iterará un hash 1000 veces específicamente para que sea más lento. "
Contraseña funciones funciones hash se construyen deliberadamente lento para frustrar los ataques de diccionario . Hacer un generador de números aleatorios lento es simplemente tonto .
En ese momento, las curvas elípticas estaban de moda
¿Eh qué?
y el generador de números aleatorios basado en hash estaba bajo escrutinio.
Tonterías . Un generador de hash basada obsoletos sola (FIPS 186) estaba bajo control - y se fija . El NIST SP800 - 90 proyecto en el que Dual_EC apareció también proporcionó tres perfectamente buenos generadores no backdoored : dos basados en funciones de hash y una basada en AES . Sam , esta afirmación es simplemente errónea .
La esperanza era que la curva elíptica técnicas basadas como están en la teoría de números -no sufren muchas de las mismas debilidades que otras técnicas (como la FIPS 186 SHA- 1 generador) que fueron vistos como negativos
Dual -CE sufre exactamente el mismo tipo de debilidades como FIPS 186 . A diferencia de los generadores alternativos en NIST SP800 - 90 que tiene un sesgo significativo y realmente no se debe utilizar en los sistemas de producción . RSA ciertamente tuvo acceso a esta información después de los análisis fueron publicados en 2006 .
y Dual_EC_DRBG era una norma aceptada y escrutado públicamente .
Y cada poco de escrutinio público , dijo lo mismo: esto está roto ! Agarra tus hijos y huir !
SP800 - 90 (que define Dual DRBG CE ) exige nuevas características como la prueba continua de la salida obligatoria , re - siembra,
Exactamente el mismo se puede decir de los generadores alternativos basados en hash y AES basada no eligió de SP800 -90.
resistencia a la predicción opcional y la capacidad de configurar para diferentes puntos fuertes .
Así que tomaste ventaja de cualquiera de estas opciones en el marco de los valores predeterminados Bsafe ? ¿Por qué no ? ¿Y los muy simples medidas de mitigación que el NIST añadido a SP800 -90A como un medio para eliminar las preocupaciones de que el generador pueda tener una puerta trasera ? ¿Alguien?
No hay mucho más que decir aquí . Creo que la mejor manera de decirlo es: todo esto es parte del proceso. En primer lugar, encuentre la enfermedad. A continuación, vea si puede curarla.
Si te gusto el artículo, danos +1, síguenos en twiter e inscríbete a Ethical Hacking en Español (Comunidad G+) y chócala con el gato, nos ayudaría muchísimo
Comentarios
Publicar un comentario