Longitud de “texto sin formato” de AES cuando se descifra con una clave incorrecta

1

Si cifro un texto X usando la clave A con los algoritmos AES, y luego descifro el resultado usando la clave B, ¿la longitud de Y del texto simple obtenida sería la misma que la de X? Si la respuesta es no, ¿existe algún algoritmo de cifrado en el que esto suceda?

Tenga en cuenta que quiero cifrar un texto sin formato de manera que, si se descifra con la clave incorrecta, la longitud del texto sin formato obtenido sea la misma que la original.

    
pregunta Lucas 29.01.2016 - 22:50
fuente

2 respuestas

2

La longitud de los bytes descifrados siempre debe ser multiplicativa del tamaño del bloque, sin importar si se usa una clave correcta o no. Por supuesto, puede haber una situación en la que el descifrado con la clave incorrecta resulte en una salida que parezca que utiliza un relleno válido y al eliminar el relleno, la longitud no es igual a la longitud original. Pero ese ciertamente no es el caso habitual.

    
respondido por el John 29.01.2016 - 23:07
fuente
2

Depende del modo de operación y del método de relleno (si se usa).

Los modos

CTR, OFB y CFB siempre producirán una longitud de texto simple después del descifrado que es igual al original, incluso si se usa una clave incorrecta o IV.

Los modos de cifrado autenticados se especifican para que no devuelvan texto sin formato si la clave es incorrecta o si el texto cifrado ha sido manipulado.

Para otros modos que requieren relleno (CBC, PCBC, ABC, etc.), la implementación puede producir resultados inesperados si no se codifica correctamente. El algoritmo de desempaquetado puede estar separado del cifrado, y puede que no tenga conocimiento del tamaño de bloque del cifrado, y permite eliminar 240 bytes de relleno, incluso aunque el tamaño de bloque para AES sea solo de 16 bytes. Esto puede ser incorrecto para usted, pero no para el código. También depende del método de relleno utilizado, y si el código Unpad comprueba explícitamente la corrección de los bytes de relleno antes de eliminarlos.

El relleno ISO / IEC comienza al final y se desplaza hacia atrás hasta que encuentra un bit 1, luego elimina eso y los 0 bits al final. Una clave incorrecta probablemente resultará en un texto plano descifrado más largo usando la clave incorrecta que la original.

El relleno ANSI y PKCS utiliza el byte final como la cantidad de bytes que se deben truncar, pero se especifican de manera diferente en cuanto al contenido de los otros bytes de relleno. Es posible que las implementaciones ni siquiera miren esos otros bytes, y solo lean el byte final para el recuento de bytes de relleno, que puede tener un valor de 0 a 255, lo que probablemente resulte en un texto plano descifrado más corto usando la clave incorrecta que el original. Es improbable que el resto de los bytes de relleno coincidan con la especificación del modo de relleno, y si se verifican, el código de unpad puede simplemente devolver todo el texto sin formato.

    
respondido por el Richie Frame 30.01.2016 - 11:42
fuente

Lea otras preguntas en las etiquetas