¿Hay fallas en este simple intercambio de claves?

Usted envía K xor R . Tu compañero devuelve R . El atacante ve ambos valores; por lo tanto, puede calcular (K xor R) xor R (el XOR de los dos valores que vio), y el R cancelar: el resultado es K . Tan debil. Terminalmente.

Si quieres algo más robusto, necesitarás una herramienta adicional, por ejemplo. una función hash criptográfica como SHA-256. Por ejemplo, todavía envía K xor R y su compañero devuelve SHA-256(R) . Éste funciona siempre que se haya elegido R de forma aleatoria y uniforme . Piénsalo; el objetivo de estos ejercicios es obtener una comprensión intuitiva de lo que está sucediendo. Aquí, su compañero está mostrando su conocimiento de R enviando SHA-256(R) , pero sin revelar nada sobre R (principalmente porque SHA-256 es resistente a preimágenes - sí, sé que estoy tomando un poco de atajo retórico aquí). Sin embargo, tenga en cuenta que este esquema es vulnerable a ataques de diccionario en caso de que la clave K sea una contraseña (es decir, algo de un conjunto que es lo suficientemente pequeño como para ser recorrido exhaustivamente).

Son posibles otras variantes con una función hash; Sin embargo, todos serán débiles con respecto a los ataques de diccionario (sin embargo, necesita PAKE para solucionarlo, y esto significa un muchas más matemáticas).

Su otro escenario es lo que básicamente es un cifrado de flujo . Puede ser fuerte, si se hace correctamente: use un algoritmo robusto, una "semilla" lo suficientemente grande (que es, en realidad, una clave), y nunca alguna vez reutilice el mismo flujo para dos mensajes distintos.

Completamente defectuoso. Un atacante puede simplemente XORAR el desafío (el "flujo de bits aleatorio") con la respuesta (la "cadena aleatoria original") y así conocer la clave secreta.

La extensión es una forma de cifrado de flujo. Para que un cifrado de flujo sea seguro, es fundamental que el mismo flujo no se repita dos veces (es decir, que se use un vector de inicialización diferente). En cualquier caso, si intenta usar un cifrado de flujo para la autenticación como se propone, estará sujeto a un ataque de hombre en el medio.

Parece que lo que estás pidiendo es un intercambio como este:

1. Alicia genera el texto en claro P.
2. Alice XORs P con clave compartida K para obtener el "texto cifrado" C.
3. Alice envía C (P XOR K) a Bob.
4. Bob calcula C XOR K para obtener texto en claro P
5. Bob envía P a Alice.

Donde se descompone son los pasos 3.5, 5.5 y 6:

1. Alicia genera el texto en claro P.
2. Alice XORs P con clave compartida K para obtener el "texto cifrado" C.
3. Alicia le envía C a Bob. 3.5 Eve intercepta y almacena C.
4. Bob calcula C XOR K para obtener texto en claro P
5. Bob envía P a Alice. 5.5 Eve intercepta y almacena P.

6. Eve calcula C XOR P y recupera la clave K.

El hecho de exponer a sabiendas el texto sin formato para el que existe el texto cifrado, básicamente hace el trabajo de un atacante, especialmente en la forma básica de "cifrado de flujo" que ha descrito. Consulte Ataque de texto simple conocido .

La segunda opción, la de los PRNG sincronizados, es igualmente problemática. ¿Cómo comunica Alice de forma segura la semilla del PRNG a Bob? Ella no puede, a menos que ya compartan una llave.

Finalmente, recuerde que una función hash es una primitiva citoprográfica específica, no una referencia al texto cifrado. Un mensaje cifrado es "cifrado", no "hash". No ser pedante aquí, simplemente tratando de evitar la pluma roja del profesor.