¿Existe algún problema con el uso de conjuntos de cifrado basados en CAMELLIA, IDEA y SEED en un servidor web en 2016?

1

Recientemente he visto las suites de cifrado CAMELLIA, SEED e IDEA en uso para HTTPS en un servidor web y no estoy seguro de qué sugerir al propietario. Las claves en uso tienen más de 128 bits de longitud y OpenSSL estándar está en uso.

IDEA ha quedado en desuso en rfc5469 debido a que no tiene un uso generalizado, pero en realidad no es inseguro.

Las posibles razones para usar los conjuntos de cifrado anteriores pueden implicar ser excesivamente paranoicos acerca de la posible interferencia de la NSA y querer utilizar conjuntos de cifrado japonés / europeo / surcoreano en su lugar. No se ve afectado por los requisitos legales locales para usar estos cifrados.

Las posibles razones para no usar estos cifrados incluyen que no se usan ampliamente en toda la industria, por lo que es probable que hayan sido investigados por la comunidad de seguridad en comparación con AES u otras alternativas. Es posible que alguien pueda desarrollar ataques de canal lateral adaptando los utilizados contra otros cifrados, pero esto es extremadamente improbable para este servidor. El soporte de ellos se ha eliminado de la mayoría de los navegadores modernos y no puedo pensar en ninguna situación en la que un cliente que pudiera usar estas suites de cifrado no fuera compatible con AES, que también estaba disponible.

Más allá de alertar al propietario sobre la desaprobación de IDEA y sugerir que generalmente es una buena idea usar las suites de cifrado estándar de la industria de facto, ya que éstas han sido las más investigadas en su contra, ¿hay algo más en lo que deba estar? consciente de?

    
pregunta Stu W 02.03.2016 - 17:35
fuente

3 respuestas

3

En general, espero que todas las suites de cifrado modernas admitan modos modernos (en este momento, generalmente GCM o CCM, con solo GCM comenzando a estar ampliamente disponibles hasta el momento).

Esto permitirá mitigar futuras debilidades algorítmicas (como el debilitamiento progresivo de RC4) al deshabilitar el cifrado débil conocido mientras aún se tienen implementados otros cifrados aún fuertes. Tener una variedad de opciones buenas y sólidas es fundamental cuando se encuentran fallas en una de ellas.

IDEA es antigua, de 64 bits, y debe estar en desuso de acuerdo con RFC5469 como notó. Recomendaría que nunca se vuelva a utilizar.

CAMELLIA es un código moderno aceptado por el proyecto europeo NESSIE en su selección final de algoritmos junto con otros otros cifrados (incluido AES).

CAMELLIA también es aceptada por el japonés CRYPTREC en su proyecto Especificaciones de sistemas de cifrado recomendados por el gobierno electrónico .

Recomendaría el soporte completo de CAMELLIA en el modo GCM según RFC6367 .

SEED es un antiguo cifrado de Corea del Sur; No recomendaría su soporte, especialmente porque no tengo conocimiento de que GCM u otros modos modernos estén disponibles en TLS; solo los modos antiguos en RFC4162 .

El cifrado más moderno de Corea del Sur es ARIA ( RFC5469 ). ARIA ha agregado varias suites de cifrado a TLS en RFC6209 , incluidas las suites en modo GCM que merecen una gran consideración. >     

respondido por el Anti-weakpasswords 03.03.2016 - 04:26
fuente
5

IDEA utiliza bloques de 64 bits. Esto significa que comienza a tener problemas, criptográficamente hablando, si encripta más de 2 bloques 32 de datos con la misma clave (en el modo CBC). Eso es 32 gigabytes, que es bastante grande, pero no es inalcanzable para los estándares actuales. Por lo tanto, debe evitarse.

Camellia y SEED son cifrados en bloque que existen principalmente porque los gobiernos japonés y coreano sufren de síndrome NIH . Por lo que sabemos, son algoritmos bastante decentes, al igual que el AES. No hay ninguna razón sustancial para creer que son más fuertes; Si estás en el lado paranoico, considera que si hay algún método desconocido por el cual el AES podría tener pinchos, entonces no hay razón para creer que la Camelia y SEED no estén igualmente afectadas.

Una razón práctica para preferir AES es que ha habido mucho más trabajo para hacer implementaciones de AES a tiempo constante. Además, algunas CPU ofrecen soporte de hardware, que es incluso mejor para la protección contra ataques de canal lateral y ofrece un mejor rendimiento. Un servidor web típico no tendrá ningún problema de rendimiento con ninguno de estos algoritmos; Si los ataques de canal lateral son aplicables en la práctica o no, nadie lo sabe.

Aún en el lado práctico, si los clientes no son compatibles con Camellia o SEED, entonces no tiene sentido habilitarlos en el servidor, de todos modos no se utilizarán.

    
respondido por el Thomas Pornin 02.03.2016 - 18:54
fuente
0

No veo una razón para favorecer, p. ej. AES sobre otros cifrados bien probados. Incluso si IDEA y otros sistemas de cifrado pueden no tener tanta información sobre su seguridad, no están sin probar.

Creo que el problema más grande sería que se use una versión anterior de TLS (o incluso una SSL antigua). La superficie de ataque creada por esto y adicionalmente a través de errores de versiones anteriores de OpenSSL es mucho más grande.

Entonces, en mi opinión (no soy criptógrafo o experto en seguridad) el uso de cifrados bien probados que no son muy populares no es un problema. Sin embargo, no aumenta la seguridad, por lo que no hay ninguna razón particular por la que desee utilizar cifrados exóticos.

    
respondido por el John 02.03.2016 - 18:36
fuente

Lea otras preguntas en las etiquetas