Un cifrado Vernam (el nombre oficial del teclado de una sola vez) es seguro porque cualquier valor cifrado se podría descifrar igualmente a cualquier valor de texto plano. Si tengo el valor de texto cifrado HFKCV, podría descifrar a HELLO, o START, o STOP !, dependiendo únicamente de la clave.
Pero la seguridad se basa en que los bytes de la clave son verdaderamente aleatorios, y la propiedad crítica es que cada byte de la clave debe estar no relacionado con todos los demás bytes de la clave. (La seguridad también se puede romper si el material clave se reutiliza, pero eso permite un ataque diferente al que describo a continuación).
El problema es que muchas de las llamadas almohadillas de una sola vez no tienen en cuenta las implicaciones de un proceso de generación de claves no aleatorias. Creen que pueden tomar la salida de rand () o la salida de un algoritmo hash, y que es lo suficientemente aleatorio. Pero estos algoritmos a menudo son deterministas y generan bytes que están relacionados entre sí, y eso es suficiente para romper el cifrado.
Usemos un "generador de números aleatorios" deliberadamente deficiente como generador de claves para demostrar la importancia del proceso de selección de números aleatorios. Esta mala rutina de números aleatorios toma la semilla, le agrega uno y la genera como un número aleatorio. Para cifrar el mensaje de texto simple HOLA con este mecanismo, tendríamos una secuencia de claves generada de 1, 2, 3, 4, 5, y el valor cifrado sería IGOPT. Como un atacante que aprende que IGOPT == HOLA, podría mirar el flujo de claves utilizado para generarlo, y notar que el patrón es 1, 2, 3, 4, 5. Eso podría habilitar la ingeniería inversa del generador de números aleatorios , y encontrar una manera de descifrar cualquier mensaje. (En este caso, aprendí que la función de cifrado ha cambiado de un teclado aleatorio de una sola vez a "adición"). La idea importante es este mismo enfoque para los trabajos de ingeniería inversa, sin importar qué "función aleatoria" se use para generar la clave. material.
-
Para responder a su otra pregunta no relacionada, 3DES usó EDE para permitir la migración de instalaciones antiguas de clave de 8 bytes a instalaciones nuevas de clave de 24 bytes. Mucho antes, cuando muchas instituciones financieras usaban un solo DES con claves de 8 bytes para proteger las transacciones bancarias y las autorizaciones de cargos minoristas. Una vez que se descubrió que un solo DES era débil, tuvieron que encontrar una manera de aumentar la seguridad mientras permanecían compatibles con versiones anteriores, porque no todos los bancos y minoristas podían sincronizar el cambio de todos sus sistemas de encriptación durante la noche. (Los bancos tendrían "módulos de seguridad de hardware" (HSM), mientras que los minoristas tenían decenas de miles de almohadillas de PIN en sus cajas registradoras. Todos ellos necesitan usar la misma clave de base para el cifrado. Cambiar algunos HSM era moderadamente caro para los bancos, pero el cambio de miles de almohadillas de PIN fue increíblemente caro para los minoristas.)
El uso de 3DES en el modo EDE le permite usar una sola clave de 8 bytes para las tres operaciones (llamada "opción de clave 3") y permanecer compatible con alguien que solo tiene un solo DES y una clave de 8 bytes. Es compatible porque el primer cifrado se revierte por completo con el siguiente descifrado, por lo que el tercer cifrado se convierte en el único cifrado que es efectivo. De esta manera, un banco podría actualizar silenciosamente sus sistemas para que sean compatibles con 3DES manteniendo la misma clave de 8 bytes, mientras que sus clientes continuaron usando un solo DES con la misma clave. Finalmente, sus clientes luego actualizaron sus almohadillas de PIN a sistemas compatibles con 3DES, lo que les permitió ser inyectados con una clave de 24 bytes. Solo así las comunicaciones estarán aseguradas adecuadamente por 3DES.