0

I try to really securely encrypt a file with OpenSSL. I´m new to OpenSSL and just read here, that it´s not very secure due to it´s behavior in generating salt & IV, and storing it within the encrypted file.

I use a Server, where OpenSSL is the only tool available for file encryption (currently I have V1.0.1t).

Let´s say, I use a password with 256 or more bytes of random data, including all kind of special chars and aes-256-cbc for encryption.

I know, the md5 of password + salt is stored in the first 32 bytes of the enrypted file now. Quite weak so far...

What if I use a little trick and read out that first 32 bytes and store them in a different location (DB, etc.). Then overwrite them in the file with random data... Later for decrypting I put the original bytes back into the file, prior to decrypting.

As far as I understand, this would be a huge increase of security, as long as no one gets access to the stored fragments.

Is this correct? What do you think?

Sandip Patidar
  • 13
  • 6
user3475261
  • 1
  • 1
  • PS: OpenSSL 1.0.1 is not supported upstream for 2 years now, and when it was t wasn't the last patch. Although the `enc` functionality is pretty basic and I don't _think_ it had any important fixes recently other than the upgrade of the default hash in 1.1.0 (see my comment on Steffen's answer). – dave_thompson_085 Oct 12 '18 at 04:24

1 Answers1

2

I know, the md5 of password + salt is stored in the first 32 bytes of the enrypted file now.

This is not true. It will only write the 8 byte salt and nothing derived from the password (not MD5, not something else) as you claim. Instead the salt and the password will be used together to derive the encryption key using MD5, but the user needs to provide the password for decryption so that the encryption key can be again derived from the (given) password and the stored salt.

The problem with enc is instead that MD5 is a weak key derivation function because it is too fast and thus simpler passwords can be brute forced. See also openssl enc uses md5 to hash the password and the salt.

If you really need to use enc use a hard password so that brute forcing will not be successful.

Let´s say, I use a password with 256 or more bytes of random data,...

Yes, this is probably hard enough: 2048 bits of random data can be well considered impossible to be brute-forced, commonly even 128 or 256 bits (16 or 32 random binary bytes or about 22..44 random alpha-numeric characters) are considered sufficient.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • Can you say something to the trick with overwriting the first bytes too? – user3475261 Oct 10 '18 at 18:06
  • @user3475261: Since the first bytes don't contain the data you assumed I don't think that your proposal is really useful. Since you want to use a strong password anyway your proposal does not add any real security (it is already secure with the strong password) and only make things more complex. – Steffen Ullrich Oct 10 '18 at 18:23
  • I found the info withe first bytes here: https://security.stackexchange.com/questions/29106/openssl-recover-key-and-iv-by-passphrase#29139 Did I get it wrong? Is there a stronger algo than aes-256-cbc in OpenSSL? – user3475261 Oct 11 '18 at 07:29
  • @user3475261: it looks like you got it wrong. It clearly and correctly describes the header and nowhere it says that the password (or a derivate) gets stored in the header. It says that the password and salt is used to derive the encryption key using MD5 bit it does not claim to store this key in the output - which would be foolish. – Steffen Ullrich Oct 11 '18 at 08:56
  • On `enc` in 1.0.x you can specify `-md sha256` so the bad PBKDF (EVP_BytesToKey) doesn't outright discard entropy aes-256 could have used. (You can specify on 1.1.0+ also, but there it's the default.) But if you have 64 hexits fully random just use `-K` (and `-iv 00`) and punt the KDF and salt altogether.. – dave_thompson_085 Oct 12 '18 at 04:11
  • 1
    @user3475261: there is nothing stronger than aes-256 anywhere, and until/unless quantum aes-256 isn't any stronger than aes-128. As The Bear has colorfully described, focussing on big numbers for cryptography is the modern equivalent of men comparing their genitals. You have hugely more risk -- zillions and zillions of times more risk -- from wherever/however you are storing this 'super-strong' password. – dave_thompson_085 Oct 12 '18 at 04:15
  • FYI, enc in openssl 1.1.1 now supports pbkdf2 for deriving a key and and iv from a password and a randomly generated salt. For example, openssl aes-256-cbc -e -salt -pbkdf2 -iter 10000 -in plaintextfilename -out encryptedfilename By default, it uses 10000 rounds of sha256 hashing. See https://www.openssl.org/docs/man1.1.1/man1/openssl-enc.html for more info. – mti2935 Mar 06 '20 at 01:15