A 43 character securely randomly generated mixed case alphanumeric password (with 2 extra chars to give 64 possibilities per character) would constitute 258 bits of entropy (6 * 43 = 258).

Since the gold standard in AES symmetric key lengths is 256 bits, am I right in concluding that GPG will use my 43 character securely randomly generated password to create an encrypted file that is just as secure as if I'd used a securely randomly generated 256 bit binary key directly (instead of deriving it from a passphrase)?

I'm looking for gotchas, such as whether despite specifying to the gpg command to use AES256, maybe the KDF will still only create a 128 bit key from my 258 bits of entropy?


migrated from stackoverflow.com Feb 23 '16 at 18:11

This question came from our site for professional and enthusiast programmers.

  • Since it's securely random, it's safe to say that it's basically base64(key)... – Olivier Grégoire Feb 10 '16 at 11:49
  • @OlivierGrégoire Yes, my passphrase will be basically base64(256 bits of entropy), but the critical question is whether the GPG KDF will derive only a 128-bit key from my passphrase, or whether any other sources of weakness will be introduced because I am forced to supply GPG with a passphrase and not a raw set of bits as a 256-bit key. – Andrew Parks Feb 10 '16 at 13:17
  • This is a moved cross post of security.stackexchange.com/questions/113309 – Richie Frame Feb 24 '16 at 0:56

There is in fact no difference in security between a 128-bit symmetric key and a 256-bit symmetric key. The reason is that security against brute force is relative to the technological means available to the attacker, and there is no way that the technology in the foreseeable future will allow a 128-bit exhaustive search to be performed with non-negligible chances of success.

By "foreseeable" here, I mean "within the next 30 years". Anybody who claims to be able to predict technological advances for longer times is either a time traveller or a filthy liar. Note in particular that it I claim that there will not be, in the next 30 years, a quantum computer that is large enough to run key tests on 128-bit AES and can do so for 264 steps -- the latter condition being very non-trivial. It is of course conceptually possible that mathematical advances will be found, that would simplify exhaustive search, but this is highly speculative and there is no real indication that a 256-bit AES key would resist such things better than a 128-bit AES key (in fact there are some esoteric attacks, called "related-key attacks", which fortunately do not apply to practical cases, and for which AES-256 is weaker than AES-128).

Since there is nothing stronger than non-breakable, one can say that AES-128 and AES-256 are equally good for security. We may even say that AES-128 is slightly preferable, since it is slightly faster (but it won't matter much).

That being said, in OpenPGP format, passphrases are turned into keys through a string-to-key transform. The recommended one (the "iterated and salted" transform) hashes a long concatenation of multiple repetitions of the passphrase and the salt. The total size of that which is hashed is configurable, but the point is that each passphrase try should cost a lot. This mechanically increases resistance to exhaustive search. For instance, if the iteration count is such that a passphrase-to-key transform costs as much as about one million AES invocations, then you only need 108 bits of entropy in the passphrase to reach 128-bit equivalent security. Of course, increased cost is increased cost: you do not get extra security for free.

The iterated-and-salted S2K uses an inner hash function which could be SHA-1 or even MD5, but it is not needy with regards to the cryptographic robustness of that underlying hash function. Even if it is the very broken MD5, and even so MD5 output is only 128 bits, the iterated-and-salted S2K is defined in such a way that it can still keep about all your passphrase entropy in the resulting key. Thus, if you have 256 bits or more of entropy in the S2K input (the passphrase), and you want a 256-bit output key, then that output key will have at least 255 bits of entropy.

(If you have exactly 256 bits of entropy in the input, you expect a theoretical 255.34 bits of entropy in the output.)

To sum up: there is no "gotcha" in the way the passphrase is turned into an encryption key, but even if there was, you would still get a security level that is not different, in any practical meaning of the term, to the theoretical "256-bit" level.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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