Encryption/Decryption Doesn't Work Well Between Two Different Openssl Versions

Encryption/decryption doesn't work well between two different openssl versions

The default digest was changed from MD5 to SHA256 in Openssl 1.1

Try using -md md5

cgs@ubuntu:~$ echo "it-works!" > file.txt
cgs@ubuntu:~$ LD_LIBRARY_PATH=~/openssl-1.1.0/ openssl-1.1.0/apps/openssl aes-256-cbc -a -salt -in ~/file.txt -out ~/file.txt.enc -md md5
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
cgs@ubuntu:~$ LD_LIBRARY_PATH=~/openssl-1.0.1f/ openssl-1.0.1f/apps/openssl aes-256-cbc -a -in ~/file.txt.enc -d
enter aes-256-cbc decryption password:
it-works!

The ugly details:

The entered password is not used as is by aes (or other encryption) but the command implicitly derives a key from it. The key derivation uses message digest that was changed in openssl 1.1 Use SHA256 not MD5 as default digest.

In case you want to keep it simple password, and not start messing with the keying martial (-K,-iv) just force the same digest with -md

How to use OpenSSL to encrypt/decrypt files?

Security Warning: AES-256-CBC does not provide authenticated encryption and is vulnerable to padding oracle attacks. You should use something like age instead.

Encrypt:

openssl aes-256-cbc -a -salt -pbkdf2 -in secrets.txt -out secrets.txt.enc

Decrypt:

openssl aes-256-cbc -d -a -pbkdf2 -in secrets.txt.enc -out secrets.txt.new

More details on the various flags

AES | Encrypt with OpenSSL, decrypt with mcrypt

I solved the problem with the empty initialisation vector by trial and error now, though I have no clue why the following was a problem at all.
Maybe someone can explain that to me.

Changing the line: int nrounds = 28; did the trick.

If i put any other number than 28 in there, an IV is generated and when I use it afterwards in mcrypt the ciphertext is decrypted in the correct way.
Why was it a problem to generate the key with 28 rounds with the openssl-function EVP_BytesToKey()?
I reduced it to 5 rounds now, but I'm curious whether this problem might happen again with a password-rounds-combination that has the possibility to generate such a Null-IV.

I don't realy know how the process of the IV generation is handled in this function.

Error while finalizing cipher with EasyCrypt library on another device

I believe your issue is that devices aren’t running the same OpenSSL versions used for encryption and decryption. I searched a different error in your error log.

Caused by: javax.crypto.BadPaddingException: error:1e06b065:Cipher functions:EVP_DecryptFinal_ex:BAD_DECRYPT

Check out this SO question for more information. I know this doesn’t answer your question fully, but I hope it gets you started.

OpenSSL 3.0.2 with custom salt doesn't start with Salted__

This isn't really programming or development and thus should be offtopic, but since you made me look:

Yes it changed, not specifically 3.0.2 but all 3.0.x (from an alpha of/before 3.0.0 through 3.0.3); see https://github.com/openssl/openssl/commit/c4c8791e145a7cb2d59e73410505e36e4d57ff78 . Now when you use -S it no longer writes or reads the 16 bytes consisting of Salted__ plus 8 bytes salt.

There is no option to control this. Of course since OpenSSL is open source you could fork and modify it as you wish, as long as you don't distribute it inconsistent with the license.

The apparent base64 difference is solely a result of this.

$ <<<U2FsdGVkX19VVVVVVVVVVQkK+WIxriO4aZHXlxJOzDg= openssl base64 -d |xxd
00000000: 5361 6c74 6564 5f5f 5555 5555 5555 5555 Salted__UUUUUUUU
00000010: 090a f962 31ae 23b8 6991 d797 124e cc38 ...b1.#.i....N.8
$ <<<CQr5YjGuI7hpkdeXEk7MOA== openssl base64 -d |xxd
00000000: 090a f962 31ae 23b8 6991 d797 124e cc38 ...b1.#.i....N.8

The actual ciphertext is identical, and a 1.x.x file could be decrypted by 3.x or vice-versa if you remove or reinsert, respectively, the first 16 bytes; the only difference is whether the first 16 bytes are there or not, which makes the base64 look different because 16 is not a multiple of 3.



Related Topics



Leave a reply



Submit