Utilidad de encryption de files sin verificación de integridad de key (key simétrica)

Al encriptar un file con key simétrica, la mayoría de las utilidades comunes (como gpg, mcrypt, etc.) almacenan información en el post encryption que se puede usar para verificar la integridad de la key durante el desencryption. Por ejemplo, si se ingresa la key incorrecta durante el desencryption, gpg replicará con:

gpg: desencryption fallido: key incorrecta

Supongamos que estoy encriptando un file que contiene una cadena que es aleatoria. Luego, la verificación de integridad de key utilizada en las utilidades estándar agrega una vulnerabilidad.

¿Hay alguna utilidad común que no almacene ninguna información o networkingundancia para verificar la integridad de key / post (y así "descifrará" un file encriptado para cualquier key suministrada)?

Como alternativa a mi otra respuesta , me gustaría ofrecer algo más. Algo hermoso … dm-crypt.

Plain dm-crypt (sin LUKS) no almacena nada sobre la key; por el contrario, cryptsetup está perfectamente feliz de abrir un dispositivo simple con cualquier contraseña y comenzar a usarlo. Permítame ilustrar:

 [root:tmp]# fallocate -l 16M cryptfile [root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pa55w0rd" 

En este punto, querrá escribir todos sus datos aleatorios en /dev/mapper/cfile-open . Me parece prudente que dimensione el file crypt original apropiadamente antes de time para que use todo el espacio; sin embargo, podría tratar esto tan fácilmente como otro poco más de security a través de la oscuridad y anotar exactamente cuántos datos escribió. (Esto solo funcionaría si los bloques subyacentes ya fueran semialeatorios, es decir, si no vas a completar el file por completo, debes crearlo con openssl rand o dd if=/dev/urandom lugar de fallocate ). … Incluso podría usar dd para comenzar a escribir en algún lugar en el medio del dispositivo.

Por ahora, haré algo más simple.

 [root:tmp]# cryptsetup status cfile-open /dev/mapper/cfile-open is active. type: PLAIN cipher: aes-cbc-essiv:sha256 keysize: 256 bits device: /dev/loop0 loop: /tmp/cryptfile offset: 0 sectors size: 32768 sectors mode: read/write [root:tmp]# b $((32768*512)) B KiB MiB GiB TiB PiB EiB 16777216 16384.0 16.00 .01 0 0 0 [root:tmp]# ll cryptfile -rw-r--r--. 1 root root 16777216 Feb 21 00:28 cryptfile [root:tmp]# openssl rand -out /dev/mapper/cfile-open $((32768*512)) [root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open 00000000 00 1d 2d 11 ac 38 c4 d3 cc 81 4f 32 de 64 01 ca |..-..8....O2.d..| 00000010 [root:tmp]# cryptsetup close cfile-open 

En este punto, he llenado mi file encryption con 16 MiB de datos aleatorios. Mira lo que sucede cuando lo abro nuevamente usando la frase de contraseña incorrecta y luego, para ser claro, lo abriré de nuevo con el correcto y verás que la información original está intacta.

 [root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pass" [root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open 00000000 89 97 91 26 b5 46 87 0c 67 87 d8 4a cf 78 e6 d8 |...&.F..g..Jx.| 00000010 [root:tmp]# cryptsetup close cfile-open [root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pa55w0rd" [root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open 00000000 00 1d 2d 11 ac 38 c4 d3 cc 81 4f 32 de 64 01 ca |..-..8....O2.d..| 00000010 [root:tmp]# 

Disfrutar.

Lo que quieres no se puede hacer con GnuPG. Sin embargo, se puede hacer con OpenSSL. Debería usar uno de los sistemas de encryption (preferiblemente AES) en un modo de secuencia como cfb o ofb. (Ver: http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation )

Normalmente, cuando uso openssl para cifrar datos, uso cbc de la siguiente manera (con o sin la encoding de base64 ( -a ) … y, por supuesto, hay otras forms de especificar la frase de contraseña y los datos de input (vea man openssl ) :

 [rsaw:~]$ openssl aes-256-cbc -e -a -pass pass:pa55w0rd <<<inputdata U2FsdGVkX180a9K5gBgip7/lgdCGCLLlRflAjK8+YwY= [rsaw:~]$ openssl aes-256-cbc -e -a -pass pass:pa55w0rd <<<inputdata U2FsdGVkX1+4uSv4uCNj2J4g7441XDioDoAb6JNn2RU= [rsaw:~]$ openssl aes-256-cbc -e -a -pass pass:pa55w0rd <<<inputdata | > openssl aes-256-cbc -d -a -pass pass:pa55w0rd inputdata 

El hecho de que obtengas resultados diferentes cada vez te indica que tu frase de contraseña está en sal, lo que generalmente es bueno. Ahora mira lo que sucede cuando uso una key incorrecta.

 [rsaw:~]$ openssl aes-256-cbc -e -a -pass pass:pa55w0rd <<<inputdata | > openssl aes-256-cbc -d -a -pass pass:pa55w0r bad decrypt 139867807664032:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596: 

Para abreviar, este modo (cbc) se usa ampliamente para encriptar files, pero obviamente no cumple con los requisitos que usted presentó. Probemos algo diferente.

 [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata U2FsdGVkX1+p64nx+/K6yCHdHw+Nmn6fSOg= [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata | > openssl aes-256-cfb1 -d -a -pass pass:pa55w0rd inputdata [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata | > openssl aes-256-cfb1 -d -a -pass pass:pa55w0r 'G 疏s v 

Si bien lo anterior cumple con sus requisitos, no hago ninguna garantía. No soy un experto en encryption. La encriptación es un gran problema. Es complicado. Diré que aes*cfb* y aes*ofb también cumplen con sus requisitos … y que debe omitir aes*ecb .

Ofreceré 2 tidbits más interesantes:

  1. Normalmente, nunca recomendaría usar keys sin sal, pero en el caso de lo que estás haciendo (cifrar datos aleatorios) … podrías omitir la sal ya que agrega una estructura más claramente definida al principio de los datos. P.ej:

     [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata U2FsdGVkX18aMT3eK4IH+XWGhp4dOSG9UJQ= [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata U2FsdGVkX18uIlFFMbsZib11UgjuITY9rNw= [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata U2FsdGVkX1+G9lAIj7RjafT9YNfO9RQXDjU= [rsaw:~]$ openssl aes-256-cfb1 -e -nosalt -a -pass pass:pa55w0rd <<<inputdata X2zi09uo6ale8A== 
  2. Cuando almaceno datos (incluso datos encriptados), la integridad es siempre una de mis principales preocupaciones. Si hay datos podridos, quiero saber para poder descartar todo el file. Utilizando un encryption de bloques como aes*cbc con openssl (o AFAIK usando GnuPG para el caso), se aes*cbc cualquier pequeña inversión y hará que el desencryption falle. Por otro lado, si lo haces bien, usar un modo de transmisión puede permitir recuperar la mayor cantidad de datos posible, ya que mantiene la corrupción local en la parte de la transmisión donde existe. Revisalo:

     [rsaw:tmp]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd </etc/services >services.asc [rsaw:tmp]$ wc -l services.asc 13965 services.asc [rsaw:tmp]$ sed '6000q;d' services.asc e6AAnnXAF74c8p52q7+klGC+JHfK91QOx+oFonAzKFoJt0DSNg2WQkdBaxv4YLst [rsaw:tmp]$ sed -i '6000s/^e/f/' services.asc [rsaw:tmp]$ sed '6000q;d' services.asc f6AAnnXAF74c8p52q7+klGC+JHfK91QOx+oFonAzKFoJt0DSNg2WQkdBaxv4YLst [rsaw:tmp]$ openssl aes-256-cfb1 -d -a -pass pass:pa55w0rd <services.asc | diff - /etc/services 5029c5029,5030 < veronica 2770/tcp %   #  *    @jeronica 2770/udp # Veronica --- > veronica 2770/tcp # Veronica > veronica 2770/udp # Veronica 

Disfrutar.

PD: No te atrevas a usar otra cosa que no sea gpg , openssl o dm-crypt. Quédate con los 3 grandes. Nada más.

Esta herramienta no almacena nada para verificar la key.

https://madebits.github.io/#r/cpp-aes-tool.md

@udkLpqc: No puedo comentar arriba, depende de usted usar la herramienta o no, pero lo que usted escribió de alguna manera no es lo que veo. Lo compilé yo mismo en Ubuntu:

 $echo -e "uvwxyz\n\n\n\n\n\n\n\n\n\n" | wc -l 11 $echo -e "uvwxyz\n\n\n\n\n\n\n\n\n\n" | ./aes -p "t" | ./aes -d -p "t" | wc -l 11 

Esto se parece a la misma cantidad de líneas para mí (obtuve el mismo resultado usando files). La herramienta es antigua, la fuente dice que es PKCS5, no PKCS7. Documenta por qué se hace eco de la contraseña, y el uso de strlen en lugar de strnlen, bueno, eso tiene que verse en context, la herramienta espera que la input provenga de un usuario directamente y usa strlen solo para nombres de file y passwords. Si planea usarlo en un context automatizado donde el nombre de file y la contraseña provienen de fonts que no son de confianza, acepto, puede que no funcionen para usted.