El patron de padding en la data descifrada es normal?

[AlbertoBSD]

Anteriormente no me había fijado la salida del descifrado por AES 256 CBC con Pad habilitado.

Normalmente uno solo espera la data original descifrada, vamos que si ciframos la palabra "hola" esperamos de vuelta la misma palabra "hola" ya descifrada.

Cuando encriptas sin padding cada bloque del tamaño  "AES_BLOCKSIZE" devuelve la misma cantidad de bloques. Pero el cifrar con Padding agrega cierta cantidad mas de datos.

Por ejemplo si ciframos 32 bytes con AES256CBC con Padding nos devuelve un buffer con 48 bytes de data

Y cuando desciframos esos 48 bytes, nos devuelve la data original de 32 bytes + un buffer "sucio" es decir que hay mas datos en el buffer, en mi caso he comprobado que para este ejemplo siempre devuelve un buffer sucio de 16 bytes y cada uno de esos bytes tiene valor de uno.

Mi pregunta es ¿Es normal esto, o solo es la forma en la que trabaja la librería ctaes?

hice un programa que muestra que independientemente del key y del IV utilizados  siempre pasa lo mismo

Código [Seleccionar] Expandir

albertobsd $ ./test_aes256cbc
key: fd792d4458dbc9bfee589482273ae061a37e24a72e95a0a5fba17109e4cb1daf
iv: 7d5559d5e50e340bb66618ceaad7ed1b
Data: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
len 48
cipher data 1117fcb2cbb27ee2f735ce4083d0aea743b51f6b7f61f59ce5a27a78bb5d454eab8b6a1733a5ad1d07b0b08ba1732e04
len 32
decipher data 414141414141414141414141414141414141414141414141414141414141414110101010101010101010101010101010
albertobsd $ ./test_aes256cbc
key: 1049354727fa2affd4410da40870f1757e211efeb96349b8576157c101fe5ab0
iv: 49547b6aac189b8487f60157d13185df
Data: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
len 48
cipher data e980ef82804a6fe5bec15dda0ad50064457c65259cd810055c38eb7c55e1d40071646c7c792e6d5a7ac6597057868267
len 32
decipher data 414141414141414141414141414141414141414141414141414141414141414110101010101010101010101010101010
albertobsd $ ./test_aes256cbc
key: 6d40ce0be48da5fcc7ede6531dae1b3613e5931a808e1ae99928ab74f74f3685
iv: ec1cebfa7894563a8329aa797610841c
Data: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
len 48
cipher data 395976ca9f00ace59ba64e8a1ee5dbaf55f45e786fada6520148d82a84c298e15b2854763a2fc82e7a62164936bf8f1f
len 32
decipher data 414141414141414141414141414141414141414141414141414141414141414110101010101010101010101010101010



De ser normal esto se podría tomar ese buffer sucio como una comprobación de que la key y el iv utilizados son los correctos?


Saludos

[kub0x]

De ser normal esto se podría tomar ese buffer sucio como una comprobación de que la key y el iv utilizados son los correctos?

Percibo que te estás esforzando bastante, pero necesitas tener claro el concepto del padding en crypto simetrica. En este caso, tu suposición es negativa, temo decirte.

En tu ejemplo tienes 32 bytes de puros carácteres 'A' o bien 0x41 en HEX. 32 bytes son 256 bit, como AES trabaja con tamaños de bloque de 128, entonces nos da justo 2 bloques.

Pero sucede, que el padding tiene que adjuntarse, en este caso, se adjunta como un bloque de 16 bytes cuya representación hexademical es 0x1010.. para que el algoritmo separe los datos del padding a la hora de descifrar.

Verás, que si realizas una prueba sobre un plaintext que no sea múltiplo de 16 bytes, a la hora de descifrar, el bloque del padding estará junto a los datos del último bloque.

EDIT: Realiza la siguiente reflexión, ¿crees conveniente que un algoritmo criptográfico nos diga si una clave aleatoria testeada es la correcta para un tupla de (IV,Ciphertext)? Lo que va a hacer es retornar un plaintext inteligible que cifre al ciphertext mediante la key aleatoria y el IV. Nada más.

Lecturas:

https://en.wikipedia.org/wiki/Padding_(cryptography)#PKCS%235_and_PKCS%237
https://crypto.stackexchange.com/questions/66646/aes-cbc-padding-why-always-attach-16x-0x10-pad

[AlbertoBSD]

Gracias Kub0x, tema clarificado. Me quedo con la reflexion y me pongo a leer los links que agregaste.

Saludos!

[Danielㅤ]

Hola compañeros, aquí dejo el link completo porque salió cortado en el mensaje de kub0x:

https://en.m.wikipedia.org/wiki/Padding_(cryptography)#PKCS%235_and_PKCS%237



Saludos