4

I'm using OpenSSL's des3 tool to encrypt a file, e.g.

openssl des3 -salt -k SUPER_SECURE_PASSPHRASE < inputFile > outputFile

Everything's working, but now I have to choose a final, fixed encryption passphrase. It doesn't need to be memorized, so obviously I'd choose some sort of randomly generated characters. However, how random is useful, and how long is useful? I'm concerned that I'll unknowingly be throwing away useful entropy.

For example, AZQBB would be a poor passphrase, probably both because of length and limited character set. But, would kecqnutaspyyhgheikfzuwkjaoitqooasujjfhhsiiwqoekihaeyhflpijfmnhssdyyy be poor due to its limited character set? Or, would dU# i?|m:v be poor due to its length? It all matters how openssl uses the passphrase to generate the bits of the encryption keys, and I haven't found that documented anywhere.

As another example, if openssl just gets its 156 bits from the 8-bit ASCII representation of the first 21 characters of my passphrase, then if I restrict myself to non-control-character low-ASCII I'll be throwing away approximately 30 bits of entropy.

So, for a highly secure passphrase, my questions are:

  • How long a passphrase do I need?
  • How diverse a character set do I need?
Daniel Griscom
  • 290
  • 1
  • 3
  • 10

2 Answers2

4

"openssl des3" is really "openssl enc -des3". The password-based key derivation is a custom, undocumented scheme which, as far as password-based key derivation schemes go, is quite weak; see this answer (especially at the end) for some details. Basically, this is equivalent to hashing the password with a couple of MD5 invocations.

What matters for passwords is entropy, i.e. not the password length or the type of characters used; entropy is a measure of what the password could have been. See this answer for details on how to compute entropy. Remember that entropy is not computed on the password itself, but by analysing the process that generated the password.

Since the key derivation scheme used by OpenSSL is quite bad, you need a lot of password entropy to achieve decent security. As a rule of thumb, the limit of computational power of serious attackers is 280 invocations of a cryptographic primitive like MD5 (rich attackers like the NSA would have much trouble reaching such computational levels; even very rich organizations like Google or Apple would find it quite challenging, and would not be able to do it discreetly). In this case, since trying a password means roughly computing two MD5, this means that the password entropy should exceed 279 -- i.e. "79 bits" because entropy (in cryptography) is normally expressed in bits (which is a logarithmic scale).

IF you generate your passphrase as a sequence of random characters in a given alphabet, with each character being selected randomly, uniformly, and (crucially) independently of the other passphrase characters, THEN entropy can be easily computed: if you use n lowercase letters (26 choices for each character), then entropy is 26n. With n = 17 (17 random lowercase letters), then entropy is close to 280, i.e. 80 bits, which, as explained above, should be sufficient. Even a small character set can be compensated for by using a long-enough passphrase, because what really matters is the entropy, not the length or the kind of character.

If you try to generate passphrases that "make sense" in some way for a human, then entropy is a lot more difficult to compute, because human psychology is very bad at randomness. Again, see the answer on entropy computation.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • So, `openssl enc -des3` generates its 156 bit encryption key by hashing the entire passphrase, so that entropy in the entire passphrase is mapped to entropy in the final 156-bit key? So that, for example, a passphrase consisting of a thousand random "a"s or "b"s ("ababbabbabab...") would do the trick? – Daniel Griscom Jan 14 '16 at 16:40
  • Key size for 3DES is 192 bits, out of which 24 are not used, so the "effective" key size is 168 bits. Yes, the passphrase processing ultimately maps the entropy into the key, so you cannot _really_ have more than 168 bits of entropy in a 3DES key. A sequence of 1000 random "a" and "b" would have entropy 1000 bits, which would be total overkill; 168 random "a" and "b" would already be sufficient to achieve the maximum entropy that you can put in a 3DES key. In practice you do not need that much; about 80 bits of entropy are enough to defeat attackers. – Thomas Pornin Jan 14 '16 at 16:47
  • Thanks, that's clear. One last note: does it matter that OpenSSL's key derivation scheme is "quite bad"? Having a "good" scheme would only prevent determining the original passphrase from a known 156-bit key, but if you have the key don't you already have everything? – Daniel Griscom Jan 14 '16 at 17:38
  • If OpenSSL's key derivation scheme was stronger (i.e., in that case, inherently more expensive to run), the requirement on password entropy would be lower. E.g. if instead of 2 MD5 invocations, the derivation used 2 millions of MD5 invocations, the attacker would be able to try a million times fewer passwords with the same computing budget; adequate strength would be achieved with 59 bits of entropy instead of 79. – Thomas Pornin Jan 14 '16 at 17:42
  • So, the poor derivation scheme means that the space of human-guessable passphrases (which often has low entropy) can be tested much more easily than the entire 156-bit space of 3DES keys. Makes sense: thanks. – Daniel Griscom Jan 14 '16 at 18:27
  • You might want to be a little careful with 3-des. It's a bit strange, and is subject to a "meet in the middle attack" that reduces the effective keyspace from 168 bits to 112 bits when k1, k2, and k3 are all independent. https://en.wikipedia.org/wiki/Triple_DES – Steve Sether Jan 14 '16 at 22:44
0

DES3 uses a maximum key size of 168 bits, so if you must use DES3 then go for the maximum key size. Since you're not memorizing the key yourself you should generate the key from a CPRNG. If you have the option you should consider AES which can have larger key sizes.

sethmlarson
  • 1,479
  • 10
  • 17
  • Yes, but where do those 168 bits come from? The ASCII representation of the first 21 characters of my passphrase? If so, then that's throwing away approximately 30 bits of entropy (assuming I don't use high ASCII or control characters). (I'm adding this to my question.) – Daniel Griscom Jan 14 '16 at 16:25
  • The formatting is making the back-ticks into a code block, for the record. If you're wondering how you can use a key with control characters, if you have it saved to a file you can run `openssl des3 -salt -k (BACKTICK)cat password.txt(BACKTICK) < plaintext.txt > encrypted.txt` – sethmlarson Jan 14 '16 at 16:38
  • Nitpick: if 'control characters' includes newline, shell command expansion with backticks or (preferred) `$( )` discards trailing newlines even if they were intended as data and unquoted it also discards leading and trailing whitespace and any embedded whitespace will and anything resembling a glob pattern may cause an error. OTOH if passphrase is the first or only line in the file, `-kfile filename` or `-pass file:filename` reads from the file without making it visible in `ps` or similar. – dave_thompson_085 Dec 31 '17 at 11:43