Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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.

share|improve this answer
The salt also makes it impractical to find locations where the same value is encrypted twice. Without salt, once you retrieve one password from a hash, you can easily search for any other occurrences of that same password. – Henning Klevjer Oct 26 '12 at 13:21

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.

share|improve this answer
The point of openssl command line functions is to just run the encryption algorithm function from the command line so one can build full applications. It's just another method of access to the library for things like shell scripts, it's not designed to be a complete system for encrypting files securely. – ewanm89 Oct 26 '12 at 20:06

You are right.

Even in password hashing, the salt should ideally not appear in the API. The reason that the traditional crypt function in UNIX takes a separate salt argument is so that the responsibility for generating the salt is deferred to the application, as is the responsibility for validating hashes. The function hashes only, and leaves it to the program to compare the bits. A different API could be designed: one which takes an optional hash. If the hash is present, then the API validates the password. If the hash is absent, then it generates a hash (with an internally generated salt, with securely produced random bits).

It is a security weakening to allow the users/applications of a cryptographic API's or command interfaces to specify their own salts or initial vectors because they might do so through poor sources of random numbers, or worse.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.