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?

  • 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). Commented Oct 12, 2018 at 4:24

1 Answer 1


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.

  • Can you say something to the trick with overwriting the first bytes too? Commented Oct 10, 2018 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. Commented Oct 10, 2018 at 18:23
  • I found the info withe first bytes here: security.stackexchange.com/questions/29106/… Did I get it wrong? Is there a stronger algo than aes-256-cbc in OpenSSL? Commented Oct 11, 2018 at 7: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. Commented Oct 11, 2018 at 8:56
  • 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. Commented Oct 12, 2018 at 4:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .