¿Es esta comunicación encriptada XOR simple absolutamente segura?

23

Digamos que Alice y Peter tienen una memoria flash USB de 4GB. Se encuentran y guardan en ambos sticks dos archivos llamados alice_to_peter.key(2GB) y peter_to_alice.key(2GB) que contienen bits generados aleatoriamente. Nunca se vuelven a encontrar, pero se comunican electrónicamente. Alice también mantiene una variable llamada alice_pointery Peter mantiene una variable llamada peter_pointer, las cuales se establecen inicialmente en cero.

Cuando Alice necesita enviar un mensaje a Peter, lo hace (donde nestá el enésimo byte del mensaje):

encrypted_message_to_peter[n] = message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n]
encrypted_payload_to_peter = alice_pointer + encrypted_message_to_peter
alice_pointer += length(encrypted_message_to_peter)

~~(y para máxima seguridad, la parte usada de la clave se puede borrar)~~

Peter recibe encrypted_payload_to_peter, lee alice_pointeralmacenado al comienzo del mensaje y hace:

message_to_peter[n] = encrypted_message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n]

~~Y para la máxima seguridad, después de leer el mensaje también borre la parte utilizada de la clave.~~ - EDITAR: de hecho, este paso con este algoritmo simple (sin verificación de integridad y autenticación) disminuye la seguridad, vea la publicación de Paŭlo Ebermann a continuación.

Cuando Peter necesita enviar un mensaje a Alice, hacen lo contrario, esta vez con peter_to_alice.keyy peter_pointer.

Con este esquema trivial, pueden enviar cada día durante los próximos 50 años 2GB / (50 * 365) = ~ 115kB de datos cifrados en ambas direcciones. Si necesitan más datos para enviar, podrían usar claves más grandes, por ejemplo, con los discos duros de 2TB actuales (claves de 1TB) ¡sería posible intercambiar 60MB / día durante los próximos 50 años! Esa es una gran cantidad de datos en la práctica; por ejemplo, usar compresión es más de una hora de comunicación de voz de alta calidad.

Me parece que no hay forma de que un atacante lea los mensajes cifrados sin las claves, porque incluso si tienen una computadora infinitamente rápida, con fuerza bruta pueden obtener todos los mensajes posibles por debajo del límite, pero este es un número astronómico de mensajes y el atacante no sabe cuál de ellos es el mensaje real.

Estoy en lo cierto? ¿Es este esquema de comunicación realmente absolutamente seguro? Y si es seguro, ¿tiene su propio nombre? El cifrado XOR es bien conocido, pero estoy buscando el nombre de esta aplicación práctica concreta que utiliza claves grandes en ambos lados. Humildemente espero que esta aplicación haya sido inventada por alguien antes que yo. :-)

Nota: Si es absolutamente seguro, entonces es sorprendente, porque con los dispositivos de almacenamiento grandes de bajo costo de hoy en día, sería mucho más barato hacer una comunicación segura que con una criptografía cuántica costosa, ¡y esto tiene una seguridad equivalente!

EDITAR: Creo que esto será más práctico en el futuro a medida que disminuyan los costos de almacenamiento.~~Puede resolver la comunicación segura para siempre.~~Hoy no tiene certeza si alguien ataca con éxito los cifrados existentes incluso un año después y hace que sus implementaciones a menudo costosas sean inseguras. En muchos casos, antes de que se produzca la comunicación, cuando ambas partes se encuentran personalmente, es el momento de generar las claves. Creo que es perfecto para la comunicación militar, por ejemplo, entre submarinos que pueden tener HD con teclas grandes, y la central militar puede tener un HD para cada submarino. También podría ser práctico en la vida cotidiana, por ejemplo, controlar su cuenta bancaria, porque cuando crea su cuenta se reúne con el banco, etc.

communication encryption

— user3123061
fuente

44

Además del esquema específico para coordinar qué parte de la clave usar, este es solo un pad de una sola vez . Pero bajo una inspección más cercana resulta que en realidad no es útil para el 99% de los casos de uso.

10

Como esta pregunta es sobre la fortaleza de un algoritmo criptográfico particular, podría ser más adecuado para crypto.stackexchange.com . Para mover su pregunta allí, puede marcar la atención del moderador y solicitar la migración.

— Bart van Ingen Schenau

12

Las OTP se inventaron hace más de un siglo y se usaron, como blocs de papel físicos reales, en ambas guerras mundiales. ( en.wikipedia.org/wiki/One-time_pad ) El problema en la criptografía entonces como ahora es el intercambio de claves.

— Gort the Robot

66

Tenga en cuenta que esto todavía le deja resolver el problema de generar suficientes claves únicas para todos los datos esperados hasta que las dos partes se reúnan nuevamente, y que las claves deben generarse a través de un proceso GENUALMENTE aleatorio: los generadores de números pseudoaleatorios son vulnerables al análisis, cada vez más a medida que haya más muestras disponibles con el mismo PRNG.

— keshlam 01 de

1

@keshlam. Generar verdaderos números aleatorios cuánticos se está volviendo muy barato. Artículo interesante en arxiv: Generación de números aleatorios cuánticos en un teléfono móvil: arxiv.org/abs/1405.0435

— user3123061

50

Sí, esta es una almohadilla única . Si el material clave nunca se reutiliza, es teóricamente seguro.

Las desventajas son que necesitaría una clave por par de directores de comunicación y necesitaría una forma segura de intercambiar el material clave antes de comunicarse.

— Vatine
fuente

52

Creo que vale la pena destacar que "teóricamente seguro" significa que está matemáticamente demostrado que es irrompible , siempre que las claves sean verdaderamente aleatorias y no se reutilicen. Esa es prácticamente la garantía más sólida que puede obtener en cualquier parte de la criptografía.

— Michael Borgwardt

1

@MichaelBorgwardt gran punto allí. En este caso, "teóricamente seguro" en realidad es mejor que "prácticamente seguro".

— Mark

2

ejemplo: tengo una clave aleatoria de 2GB que tiene 16 bytes secuenciales de 0.

— Michael

@Michael Las posibilidades de que eso suceda son alrededor de 1 en 10 ^ 27.

— este

1

@Floris Mi "cálculo": un byte tiene 256 valores posibles. Es uno de cada 256 que todo será cero. 256 ^ 16 para tener la oportunidad de 16 bytes. Y luego divida el número de bytes en 2GB por esa posibilidad. Creo que me perdí una división por 16, de todos modos aquí (1024 * 1024 * 1024 * 1024 * 2 * (1/16)) / (256 ^ 16) Su último punto hace que este cálculo sea irrelevante de todos modos.

— este

32

Como indica la respuesta de Vatine , su algoritmo es básicamente una plataforma de una sola vez.

Sin embargo, para comentar una de sus notas:

Nota: Si es absolutamente seguro, entonces es sorprendente porque hoy en día tiene grandes memorias de bajo costo, es prácticamente una forma mucho más económica de comunicación segura que la criptografía cuántica costosa y con una seguridad equivalente

Mi respuesta es no, no es sorprendente. El diablo siempre está en los detalles, y el diablo aquí está en el intercambio de llaves. Su método depende de un intercambio de claves cara a cara impecable. No puedo permitirme enviar a James Bond con un disco flash de 4GB para mí a todos los comerciantes en Internet cada vez que quiera comprar algo o tener otras conexiones seguras.

Y, por último, el aspecto XOR de su algoritmo no es importante. Un cifrado de sustitución simple está bien con un OTP. La fortaleza de la OTP es que la clave nunca se reutiliza, y supone que James Bond está intercambiando las claves sin problemas para ambas partes (es decir, el intercambio de claves seguro previo)

— whatsisname
fuente

13

La otra cosa acerca de un OTP es que la clave es (al menos) tan larga como el mensaje para encriptar, y necesita una fuente de números aleatorios de muy alta calidad.

— Donal Fellows

Muchos algoritmos de cifrado funcionan de alguna manera convirtiendo una clave en una secuencia de datos que no se puede distinguir de los datos aleatorios, y luego usan esos datos como una almohadilla única. Desde la perspectiva del atacante, no hay diferencia entre los datos que son verdaderamente aleatorios y los datos que no se pueden distinguir de los datos aleatorios (por definición; si encontraste una diferencia, no era indistinguible), por lo que en teoría esto es tan seguro como OTP . Por supuesto, cuando decimos que los datos no se pueden distinguir de los datos aleatorios verdaderos, generalmente hay muchas advertencias. Esta explicación es, por supuesto, una gran simplificación excesiva.

— Brian

21

Si bien la plataforma única tiene una garantía de privacidad incondicional (probada matemáticamente) contra un atacante que solo puede leer mensajes, tiene algunas debilidades.

Un atacante interceptor que adivine correctamente el texto sin formato puede manipular el texto cifrado a lo que quiera (con la misma longitud).
Si un atacante inserta o elimina algún mensaje (o parte del mismo), los punteros de Alice y Bob se desincronizan y cada comunicación futura se interrumpe.

Actualización: Esto supone que ambas partes realizan un seguimiento de ambos punteros. Si envía el valor actual del puntero, es vulnerable a los ataques de dos tiempos (si permite que se use el mismo rango de clave más de una vez) o ataques de DOS (si no permite el mismo rango de clave para usarse más de una vez, por ejemplo, eliminándolos).

Ambos problemas son causados por la falta de integridad y protección de autenticación: tiene un cifrado perfecto, pero no MAC.

Agregue un MAC a su protocolo de plataforma única para que sea realmente seguro. Cada mensaje debe obtener una "suma de verificación" que garantice que realmente fue enviado por el supuesto remitente y que no fue modificado en el medio. Además, debe enviar algún número de secuencia para que el receptor sepa qué parte de la clave usar cuando se pierde un mensaje anterior (o rechazar el mensaje si está duplicado). Incluya esto en el cálculo de la suma de verificación.

Aquí funcionaría un algoritmo MAC habitual, pero supongo que es posible que desee utilizar un MAC polinomial único para tener una seguridad coincidente con su plataforma única. (Tome la clave MAC de los bits antes o después de su clave de cifrado, es decir, no reutilice una clave para ambos objetivos).

— Paŭlo Ebermann
fuente

Si un atacante inserta o elimina algún mensaje (o parte del mismo), los punteros de Alice y Bob se desincronizan y cada comunicación futura se interrumpe. Los punteros son independientes y no necesitan estar sincronizados, por lo que no se interrumpe la comunicación futura si se pierde el mensaje (el desplazamiento real de la clave utilizada para cifrar el mensaje se envía con ese mensaje). Pero tiene razón en parte: la sincronización se usa parte de la clave en el lado de recepción que no se borra porque no se recibe el mensaje eliminado (la parte usada se borrará con el siguiente mensaje recibido).

— user3123061

Pero tienes razón. Se presenta un algoritmo simple para la integridad y la autenticación. La implementación práctica deberá ser más robusta.

— user3123061

@ user3123061 No solo ignoraría la integridad y la autenticación si fuera usted. La técnica del ataque adaptativo de texto cifrado elegido explota la ausencia de protección de integridad para romper la confidencialidad . Me atrevería a decir que la almohadilla clásica de una sola vez (que es lo que ha reinventado) es totalmente insegura , a pesar de su aparente solidez matemática, solo por este ataque.

— zwol

2

El ataque adaptativo de texto cifrado elegido es una elección bastante pobre de ataque contra un OTP controlado por humanos. OOS se notará y tu atacante será golpeado bastante rápido. Solo si el receptor se procesa a máquina y produce una respuesta, este ataque es bueno en absoluto.

— Joshua

@Zack Hay muchos problemas con las OTP, pero ninguno amenaza la confidencialidad. Tenga en cuenta que incluso si adivina perfectamente la clave plantext + del mensaje anterior, el siguiente mensaje se cifra con una clave independiente completamente nueva (también de tamaño considerable). No hay nada a lo que adaptarse en múltiples interacciones.

4

En realidad no es del todo seguro. Lo que pierde su protocolo es la LONGITUD del mensaje comunicado.

Por ejemplo, si el espía sabe que responderá con "sí" o "no" y ve la longitud = 2, puede deducir que es "no".

En realidad, es sorprendente cuánto se puede deducir solo de longitudes conocidas si se puede adivinar el contexto.

— w.pasman
fuente

3

Sin embargo, eso es bastante fácil de solucionar, a un nivel razonable de seguridad, ya que puede rellenar el mensaje con basura aleatoria, por lo que la longitud del mensaje son múltiplos de un tamaño de bloque fijo, digamos 256 caracteres. Eso derrotaría un simple análisis sí / no, a un costo de usar el OTP más rápido.

— Peter Bagnall

De hecho, dado que puede enviar ~ 115kB todos los días durante los próximos 50 años, puede esperar que cada bloque sea de al menos 20kb, lo que significa que la longitud no es tan importante.

— apnorton