OpenSSL 3.0.2 with custom salt doesn't start with Salted__

user_887074 0
Viewed 174

I have just upgraded my Ubuntu system to 22.04 which comes with OpenSSL 3.0.2. Previously I was using 1.1.1f, and it seems the behavior has changed, but I'm not sure (1) why and (2) how to get the old behavior or what the new behavior is so I can adapt to it.

The issue is that I was expecting any openssl encrypted file to start with the bytes: "Salted__" or "U2FsdGVkX1" in Base64. I'm using that to determine if the file is encrypted or not.

If I use OpenSSL 3 with randomly generated salt things work fine.

echo "foo" >secret.txt
ENC_PASS=chbs openssl enc -aes-256-cbc -md sha256 -pass env:ENC_PASS -e -pbkdf2 -in secret.txt -a

Results in:

U2FsdGVkX1+BM+juJUWhy5eqBJ3k5BrrTs/V4l0QstA=

And I get a similar result with version 1.1.1f, but it's random so it's non deterministic.

However, in the application I'm working on, I need determinism, so I need to provide the salt. That's not a big deal openssl lets you do that with -S. On 1.1.1f I can do that and get:

ENC_PASS=chbs openssl enc -aes-256-cbc -md sha256 -pass env:ENC_PASS -e -S 5555555555555555 -pbkdf2 -in secret.txt -a

U2FsdGVkX19VVVVVVVVVVQkK+WIxriO4aZHXlxJOzDg=

This is deterministic, so you can use the same secret I did and get the same result.

But on 3.0.2 with the same command I get:

CQr5YjGuI7hpkdeXEk7MOA==

This is also deterministic, but why is it different? There doesn't seem to be a consistent pattern.

What happened? Did they stop prepending the salt to the message? Do I just have to manually add that bit if I want it? Is there anything I can do to get openssl to do that for me again? What was the reason for the change in behavior?

openssl
1 Answers

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.

user_28688010
Related