Autenticación segura incondicional

-1

Estoy tratando de agregar la autenticación para la implementación de mi One-Time Pad.
Sé que para proporcionar una autenticación segura incondicional, necesito usar el Autenticación MAC por única vez .

Pero no entiendo por qué una solución como la siguiente (que es mucho más fácil de implementar) no proporciona el mismo nivel de seguridad: /

ciphertext = ((plaintext || H(plaintext)) XOR OTPKey)

With:
|| = concatenation
H = SHA-2
OTPKey is long enough to encrypt the plaintext and H(plaintext)

Mallory no puede forzar el texto cifrado (debido al teclado de una sola vez), por lo que no puede obtener el texto claro correcto ni el resumen ...

¿Es esto correcto? ¿Puede esto proporcionar una autenticación incondicionalmente segura?

Sé que en la práctica es vulnerable a conocido - ataques de texto claro así que, por favor, no lo considere en este caso particular. Estoy interesado en la seguridad incondicional en el sentido de que tanto el texto en claro como el compendio pueden beneficiarse de la seguridad de la información teórica proporcionada por One-Time Pad.
Me interesan los ataques pasivos y no los activos.
Supongamos que Mallory aquí solo conoce el texto cifrado ;-)

En otras palabras: ¿puedo estar seguro de que un atacante no puede obtener el texto plano que explota las posibles vulnerabilidades introducidas por el uso de una función hash para el cálculo de resumen?

Variante
¿Qué tal esta variante? ¿Puedo decir que proporciona seguridad teórica de la información para el texto sin formato Y es vulnerable contra ataques activos con una complejidad de 2 ^ 256? Por lo tanto, en este caso, también puedo proporcionar un cierto nivel de seguridad contra ataques de texto sin formato conocido (incluso si es seguridad computacional).

ciphertext = (plaintext XOR OTPKey)
message = (ciphertext || H(ciphertext || K2))

With:
K2 = 32 bytes of random key, NOT correlated with OTPKey

Gracias a todos :)

    
pregunta Riccardo Leschiutta 05.12.2015 - 20:22
fuente

1 respuesta

1
  

puedo estar seguro de que un atacante no puede obtener la explotación de texto sin formato   posibles vulnerabilidades introducidas por el uso de una función hash para   ¿El cálculo del resumen?

Creo que estás a salvo. Creo que el único problema podría ser con la implementación de OTPKey. No puede reutilizar la misma clave dos veces, tiene que ser verdaderamente aleatoria, y la clave en sí misma debe ser segura y conocida por ambas partes. Además, el contenido del mensaje debe ser completamente impredecible, de lo contrario, la clave será teóricamente vulnerable a los métodos de ataque de fuerza bruta. Debido a esto, adicionalmente implementaría un valor aleatorio al principio del mensaje para que sea XORd con el resto del mensaje antes que nada. Aparte de eso, digo que todos los motores se van.

Actualizar

Sobre este método:

ciphertext = (plaintext XOR OTPKey)
message = (ciphertext || H(ciphertext || K2))

With:
K2 = 32 bytes of random key, NOT correlated with OTPKey

Esto debería ser efectivo siempre que el atacante no pueda conseguir K2

    
respondido por el Jonathan Gray 05.12.2015 - 21:57
fuente

Lea otras preguntas en las etiquetas