9
$\begingroup$

I'm encrypting a file with sensitive information with

cat secret | openssl aes-256-cbc -a -salt > secret.enc

I am choosing a random encryption password with openssl rand -base64 32 | head -c [password-length]

Is there any standard, how long it should be? Given the password length, how long would it take to crack and view the contents of the file?

I have read this article, but it seems it supposes that you use a password size of 256 bits.

Edit: I found this picture, which pretty much answers my question. Is it reliable?

https://www.inetsolution.com/blog/june-2012/complex-passwords-harder-to-crack,-but-it-may-not

$\endgroup$
2
  • 1
    $\begingroup$ given the wording of the question, it appears you have a misunderstanding of how all this stuff works. AES-256 uses a 256-bit key, thats where the 256 comes from, and if you are choosing a random key, there is no password $\endgroup$ Commented Apr 27, 2016 at 10:56
  • $\begingroup$ @RichieFrame Sorry, mixed up key and password. I think I found the answer in the link. $\endgroup$ Commented Apr 27, 2016 at 11:57

3 Answers 3

9
$\begingroup$

AES supports three key lengths. They are 128, 192 and 256 bits long. You chose to use the 256 bit algorithm that operates in CBC mode. It's a correct choice.

Now all you need is:

  • key - 256 bits long
  • initialization vector - 128 bits long

You can generate them using the command I found here:

openssl enc -aes-256-cbc -k secret -P -md sha1

where the "secret" is your password.

I suggest not using a truly random key and IV, because you have to save them somewhere, and adversary can just read it from your hard drive. It's much better to use a long and complicated password that he has to read from a post-it-note glued to your monitor, and derive the key and IV from it.

As for security, let me put it this way. If I wanted to crack 256 bits long key and 128 bit long IV on my work laptop, I would probably be around a fifth of way done when the universe would collapse. It's much simpler to use rubber-hose cryptanalysis in this case.

EDIT:

Just for you to know you shouldn't use password as a key directly. You need to derive a key from a password. The command I pasted does exactly that. About the security of the password you already answered yourself. 9 characters is the absolute minimum (if there is at least one uppercase letter, one lowercase letter, one number and one symbol). But I strongly suggest using a passphrase instead of a password. They are vulnerable to dictionary hacking, but if you use enough words a dictionary hack also takes years to complete.

There are over a milion words in the English language.

If we use only lowercase letters in our four word passphrase, the dictionary hack has to do in the worst case $1000000^{4} = 10^{24}$ searches. In comparison, there are around 100 characters on the keyboard. A password of 12 of those characters will be cracked in less than $100^{12} = 10^{24}$ searches.

This mean that "singing retracted eleventh elephant" is an equivalent of a 12 character password, and also it's much easier to remember. And if we use a comma somewhere, uppercase letter, or use a word from a different language it gets much safer.

$\endgroup$
3
  • $\begingroup$ Sorry @Filip Frank, I think I mixed up password and key. I ment the password length, how long would it take given a truly random password. I think I found it in the link, but would be great with some calculations as well. $\endgroup$ Commented Apr 27, 2016 at 12:01
  • $\begingroup$ @user1506145 If the password is on a frequently used password list: not long enough. $\endgroup$
    – zaph
    Commented Apr 5, 2018 at 15:32
  • 1
    $\begingroup$ @FilipFranik The IV should be random and does not need to be secret so a common method is to prefix the encrypted data with the IV. $\endgroup$
    – zaph
    Commented Apr 5, 2018 at 15:34
8
$\begingroup$

Suppose you use 128 characters out of an alphabet (this is a large alphabet). To create a key you'd need about 37 fully random characters to create an AES key of 256 bit strength. Even you would create such a password, you'd have trouble encoding it over the required number of bits. You could either use a 44 character base 64 string or 64 character hex string as well - at least those would be easy to decode/encode to/from bytes. In general, people don't use those kind of passwords.

This is why password based key derivation functions such as bcrypt or PBKDF2 are being used. These strengthen the password using salt and a work factor (or iteration count for PBKDF2). Although still less then perfect, they allow you to use passwords relatively securely.

In general you should look up Password Based Encryption or PBE. This is for instance specified in the PKCS#5 standards (which defines PBKDF2).


The default OpenSSL implementation uses a scheme called EVP_BytesToKey. It uses an 8 byte salt and an "iteration count" set to 1. Due to the non-existent work factor you are best off specifying all 37 characters if you want to achieve such high level security.

In the end you're better off using e.g. PGP public / private key encryption. 128 bits of security is usually sufficient; the chance that your password is compromised is much larger than that anybody with a quantum computer tries to hack your file.

$\endgroup$
0
-4
$\begingroup$

A collection of passwords and passphrases with a total of 100 characters results in a search space of 5.98 x 10^197. By comparison, there are roughly 10^80 atoms in the known universe.

If you want to super-secure your encrypted files, encrypt them first with Blowfish 448, then again with AES-256, both times using a different random password combined with a different long passphrase.

By encrypting it first with Blowfish, you're also randomizing the data, which makes even correctly decrypted AES-256 files appear as if they're still encrypted. Thus, no program or human can tell if a password guess was decrypted or not.

In this sense, you don't need a super-strong password for the Blowfish layer. A simple passphrase like "There ain't always nothing about Makia ain't what I swimmmingly done know." provides more than enough "security" for this randomizing layer. That's a keyspace of 6.06 x 10^142 in and of itself. Combined, you're looking at a level of complication on the order of 10^340.

In summary:

  1. Encrypt with Blowfish 448 using a relatively simple passphrase mixed with a random password.
  2. Encrypt with AES-256 using a different relatively simple passphrase mixed with a different random password.
    1. Ensure that neither passphrases nor passwords will ever appear in any dictionary or body of literary work.
$\endgroup$
4
  • 5
    $\begingroup$ No only is this questionable advice, but most of it has nothing to do with the question. $\endgroup$
    – otus
    Commented Apr 4, 2018 at 4:35
  • $\begingroup$ Also, your scheme is vulnerable to a MITM-attack allowing to find the keys using $2^{448}+2^{256}$ operations instead of the desired $2^{448} \cdot 2^{256}$ operations. $\endgroup$ Commented Apr 4, 2018 at 9:44
  • $\begingroup$ @VincBreaker True, but I would not like to buy the hardware for that :P, besides CPU it would also require a "few bits" of memory. $\endgroup$
    – Maarten Bodewes
    Commented Apr 4, 2018 at 14:08
  • 1
    $\begingroup$ My take is that Mugs is just trolling and knows full well that the answer is ridiculous. Note Mugs is a new user ID. $\endgroup$
    – zaph
    Commented Apr 5, 2018 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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