Implementación de hardware del algoritmo de cifrado

Question

Implementación de hardware del algoritmo de cifrado

#1 de Tom Leek (4 votos)

1

En el resumen de AES-GCM RFC , el siguiente pasaje se incluye prominentemente:

[AES-GCM] se puede implementar de manera eficiente en hardware para velocidades de 10 gigabits por segundo y superiores ...

¿La facilidad / eficiencia de la implementación del hardware es una consideración importante en el conjunto de cifrado o en el modo de cifrado? Si es así, ¿qué importancia tiene en la popularidad del sistema?

Más prácticamente, ¿hay ejemplos de cifrados comunes que presentan serios desafíos en la implementación? ¿O esto los descartaría de inmediato?

Competición AES

Sobre la sugerencia de LateralFractal, observé los criterios de evaluación de diseño para la competencia AES . Hay una línea que hace referencia al hardware (el criterio se da como "Adecuación de hardware y software"). Dicho esto, esto todavía no habla en la medida en que se tiene en cuenta este criterio.

Ejemplo DFC

Este documento que describe un ataque a DFC parece ser un buen ejemplo del mundo real. Teniendo en cuenta que el propio Thomas Pornin de este SO tuvo un papel en el desarrollo del cifrado, me gustaría saberlo:

La gravedad de este ataque propuesto a los ojos de la comunidad
La respuesta de los autores cifrados
Posibles formas en que este ataque podría haberse evitado

cryptography encryption hardware aes

pregunta msuozzo 16.10.2014 - 03:28

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography encryption hardware aes

¿Por qué agregar “***” en user-agent en este código malicioso? El servidor web tiene un archivo sospechoso

score 4 · Answer 1

El concurso AES recibió 15 candidatos, dos de los cuales sufrieron "interrupciones académicas" (debilidades que son solo teóricas, pero que aún demuestran que el cifrado de bloque subyacente no es "de una seguridad óptima"). Los 13 restantes son, hasta donde sé, aún sin interrupciones hasta el día de hoy.

Por lo tanto, la elección de Rijndael tenía que hacerse por razones distintas a la seguridad. El rendimiento, en particular la facilidad de implementación eficiente en varias plataformas de software y hardware, fue lo que importó al final. Rijndael fue elegido porque se comportó bien en muchos sistemas. En una PC, RC6 fue más rápido, pero en otras plataformas (CPU basada en RISC como Sparc, CPU de 8 bits en tarjetas inteligentes, FPGA ...) Rijndael fue más rápido / más barato (RC6 requiere una multiplicación de 32x32 bits, lo cual es barato cuando ya lo tienes, no así cuando no lo tienes). Para el caso, DFC fue peor, ya que necesitaba una multiplicación de 64x64. El "ataque" descrito por Harvey es más una observación de que la reducción de módulo 2 ⁶⁴ +13, aunque se puede hacer sin una división (lo que sería aún más costoso), puede ser difícil de hacer. > apropiadamente , es decir, sin filtrar información (consulte ataques de tiempo ).

Otros criterios informales incluían el hecho de que el programa clave de Rijndael también era rápido (en contra de, digamos, Twofish), y que los inventores de Rijndael pertenecían a un pequeño país pintoresco (no controvertido, no amenazante) que, por lo tanto, es más probable para llevar a la adopción mundial.

Como otro ejemplo, casi toda la competencia SHA-3 fue sobre el rendimiento. Todos los 14 candidatos de la segunda ronda son "igualmente fuertes" (no sabemos cómo romper ninguno de ellos, incluso de una manera académica poco realista) pero no fueron equivalentes cuando se implementaron en software o hardware. Los criterios de elección ultimate nunca fueron claros por NIST (y parece que cambiaron a mitad de la competencia), pero el hecho de que Keccak sea diabólicamente rápido en hardware (ASIC / FPGA) fue sin duda un factor decisivo para su victoria.