I want to securely encrypt files, with an open algorithm.

So, i've constructed the simple openSSL shell command. How secure is it?

function aes-enc() { openssl enc -aes-256-cbc -e -in $1 -out "$1.aes" }
# Now, encrypt zip archive.
aes-enc hello.zip

What could be improved here? How long should the passphrase be in order to make the brute force unfeasible?

Should I use something else instead of OpenSSL?

2 Answers 2


If you are using a simple passphrase-based approach, then your encryption is at most as secure as your passphrase. And even if you are using a long passphrase, your encryption is at most as secure as the key derivation function used to get from the passphrase to the actual key. Openssl uses a simple MD5 hash to generate the key, which has two drawbacks:

  1. It limits your effective key length to 128 bits, so even with a long passphrase, there is not point in using AES-256 over AES-128.
  2. Its security from collision attacks is in doubt. Now whether this is a problem for a simple file encryption scheme i don't know.

The weakest link will be the passphrase itself though. How long does it have to be? Well the better question is: how much entropy does it need? This question can only be realistically answered if the passphrase is randomly created. Take as an example diceware: here each word in the passphrase has 12.9 bits of entropy, meaning that an attacker has to try all 7776 words in the diceware dictionary to decrypt the file (well, yes, statistically, the attacker will succeed after half that number). A five word diceware passphrase gives you about 64 bits, a ten word passphrase about 129 bits of entropy. This means that you need a ten word passphrase to have the MD5 hash of openssl cut entropy off, and shows how much weaker than the other links the passphrase usually is.

  • Previous versions of openssl used a very weak key derivation process to derive an encryption key from the password, as correctly stated in this answer. However, version 1.1.1 of openssl now supports key derivation using PBKDF2, with a randomly generated salt and multiple iterations (10,000 by default) of sha256 hashing. See security.stackexchange.com/questions/31492/… for more info.
    – mti2935
    Commented Apr 10, 2020 at 17:46

8 years later, the answer seems to be:

  1. Use argon2id or scrypt with high parameters and some salt to transform 12-word BIP39 mnemonic or 12+ character password into 32-byte key.
  2. Use xchacha20poly1305 to encrypt file contents. Use key from step 1 and generate new 24-byte nonce every time from CSPRNG, then prepend nonce to encrypted file contents.

You must log in to answer this question.

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