Comprobación de la contraseña en el contexto del cifrado simétrico

2

Tengo entendido que los cifrados de bloque como AES no tienen ningún mecanismo incorporado para verificar la integridad de los datos en el descifrado, aunque algunos modos de operación pueden proporcionar eso.

He jugado con 7-zip, que utiliza AES-256 / CBC. Cifre un montón de archivos y lo corrompí deliberadamente, poniendo a cero un par de bytes. Observé que, como era de esperar, cuanto antes pusiera a cero los bytes, más archivos se corromperían.

También noté que proporcionar una contraseña incorrecta no detendría la descompresión. Solo después de descomprimir todo el archivo, 7-zip informaría que la contraseña podría estar equivocada. Dado que guarda las sumas de comprobación de los archivos, puede determinar si están dañados. Esto tiene sentido.

Ahora ingrese Adobe Acrobat X. Encripté un PDF (AES-256 nuevamente). Para mi sorpresa, los bytes corruptos en el archivo cifrado parecían no tener un efecto observable en el resultado. Tenga en cuenta que Acrobat X también encripta los metadatos, y edité algo más allá de donde yo esperaría que los metadatos fueran de todos modos.

Todavía pude ver la lectura del archivo completo. Luego eliminé la contraseña de los archivos original y "dañado" e hice comparaciones byte a byte. Noté que además de algunos rangos de direcciones donde presumo que los metadatos están almacenados (ya que difieren cada vez que descifro el mismo archivo), solo había un bloque único donde 16 bytes (coincidentemente el tamaño del bloque de AES) son diferentes.

Acrobat también parece poder verificar si una contraseña es correcta sin intentar descifrar nada, lo que implica que tiene un hash (o algo) almacenado en alguna parte.

  • ¿Tiene sentido hacer eso (verificar que una contraseña o clave es correcta sin intentar descifrar)? ¿No haría eso más fácil para un atacante la fuerza bruta de la contraseña?
  • ¿Tengo razón al suponer que Acrobat usa el BCE? ¿Hay alguna ventaja?
  • ¿Cómo se comportan los modos AE cuando se trata de:
    • La verificación de una clave es correcta antes de intentar el descifrado
    • Si un byte de texto cifrado se daña accidentalmente, ¿cómo afecta eso a lo que viene después?
pregunta quantumSoup 17.10.2012 - 21:50
fuente

1 respuesta

3

Si el esquema de encriptación utiliza CBC y modifica un bit de la datos encriptados , luego, al descifrar, esto tendrá dos efectos: distorsionará el bloque correspondiente y cambiará el bit correspondiente en el siguiente bloque (16 bytes más, con AES). No alterará el resto de los datos. Esto es muy diferente a lo que sucede si le das la vuelta a un bit de los datos de borrar , al encriptar: eso alteraría todos los bloques subsiguientes, hasta el final del archivo.

Para otros modos, las cosas varían. Al voltear un bit de datos cifrados solo se voltea el mismo bit de los datos claros con los modos OFB y CTR. Con el BCE, altera exactamente un bloque. Con CFB, modificará todos los bloques subsiguientes.

Para los modos autenticados, el CTR a menudo se usa internamente (por ejemplo, con EAX ) pero el punto es discutible porque la integridad check detectará la alteración y la informará (aún depende de la aplicación deshacerse de todo lo que haya descifrado en ese caso).

Es habitual incluir una comprobación explícita de la contraseña (por ejemplo, OpenPGP ) y no debilita el cifrado, si se hace correctamente . Básicamente, la contraseña debe tener un hash lento (con un salt), y luego se utiliza un hash de la clave resultante como suma de comprobación. En cualquier caso, ningún atacante sano descifrará el archivo completo para cada contraseña que intente: simplemente descifra los primeros dos o tres bloques para ver si encuentra un encabezado de archivo de aspecto realista. No podemos confiar en la velocidad de descifrado como sustituto del hash lento.

    
respondido por el Thomas Pornin 17.10.2012 - 22:10
fuente

Lea otras preguntas en las etiquetas