I don't see how "-salt" in the openssl command line tool enhances security at all

Question

I do this to encrypt a single file:

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

and then type in some regular plaintext password.

I do not understand how -salt enhances the security of this. The reason is that the salt is stored right there in the beginning of the file like this:

Salted__<eight salt bytes>

The salt being available to the cracker in such an obvious manner, what is the purpose of it? I don't see how it would make a dictionary attack harder ... especially given the fact that, as far as I know, openssl only uses one iteration to generate the IV from the password/salt - correct me if I'm wrong.

Answer 1

The point of the salt is to prevent precomputation attacks, such as rainbow tables. Without a salt, anyone could just generate a huge dictionary of hashes and their associated plaintexts, and immediately crack any known hash. With the salt, such a dictionary is useless, since it's infeasible to generate such a dictionary for all possible salts.

I did a pretty in-depth writeup that covers this problem over at How to store salt?, which is worth a read.

Answer 2

OpenSSL uses the salt in combination with the password to generate two values: the IV, and the actual encryption key.

• The encryption key must be derived from the password and whatever data is present in the file header (because we want to be able to decrypt the file with knowledge of the password only). However, we do not want to get the exact same key every time we use the same password, because otherwise attackers could try to break N files for less cost than N times the cost of breaking one. An example of cost sharing is precomputed tables (tables of password-to-key mappings), rainbow tables being a special case of precomputed tables.

• The IV must be as uniformly random as possible; there again, two distinct files should use distinct IV, even if encrypted with the same password. One possible design would have been to add the IV in the file header (after all, the IV is not meant to be secret -- otherwise we would call it a key, not an IV). The OpenSSL developers preferred to derive the IV from the password, just like the key (i.e. they produce from the password a long sequence, which they split in two, one half being the encryption key, the other half being the IV). This is valid, as long as some distinct element is added in the mix, because two distinct files must have distinct IV. The salt does that, too.

Note that the encryption method used by OpenSSL is not standard; it is "what OpenSSL does" but is not documented anywhere except in the OpenSSL source code. As an encryption file format, it is a bit lousy. In particular:

• There seems to be no way to configure how many iterations should be used in the password-to-key derivation. This is an issue because configurable slowness is important to cope with the main issue of passwords, which is that they are, after all, passwords, i.e. things with not too high entropy in the best case.

• The encryption system does not include a MAC so alterations are not necessarily detected (they are not detected at all if the last two blocks of the padded file are unmodified).

Therefore you are encouraged to use, if possible, a better tool for password-based encryption of files. For instance GnuPG.