13

They say algorithms like AES can't practically be broken given a long enough key length (> 128 bits). If I use GnuPG to encrypt a file using AES:

gpg -c --cipher-algo AES secretfile

it asks me for a passphrase. I understand that along with my passphrase, a salt and a key derivation function is used to generate a 128-bit key for the encryption. My question is, can't a dictionary attack be used on the passphrase to break the encryption? In that case, I would think that the encryption is not extremely strong, not good enough for the US government's "classified information". Am I missing something here?

EDIT: The answerers seem to agree that the passphrase is the "weakest link". My response question to this argument is: then why use long key lengths? Aren't these supposed to make the encryption harder to break? In other words, 192-bit AES encryption with a certain passphrase is supposedly stronger than 128-bit AES encryption with the same passphrase (correct me if I'm wrong). But if the way to break the encryption is to use a dictionary attack, then key length should be irrelevant. Is this reasoning incorrect?

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
Mukul
  • 131
  • 1
  • 4
  • Worth migrating to security.stackexchange I think. – Rory Alsop May 07 '11 at 15:17
  • Another complication is knowing when you've succeeded. I don't know if this applies to GnuPG files, but see also [time to crack file-encryption password - more than just iteration](http://security.stackexchange.com/questions/3494/time-to-crack-file-encryption-password-more-than-just-iteration/3503#3503) – nealmcb May 07 '11 at 17:44
  • 2
    @nealmcb: there is an integrated checksum in the OpenPGP symmetric encryption format -- so that people who type the wrong password get an appropriate error message, not a big blob of random junk. – Thomas Pornin May 07 '11 at 18:30
  • @thomas - interesting. I wonder what it takes to turn that off.... – nealmcb May 07 '11 at 18:59
  • 2
    @nealmcb: even if you remove the checksum, the attacker can still test for success by seeing if the decrypted data "makes sense". With GnuPG, encrypted files are first compressed (zlib) so a properly decrypted file must have a valid zlib format -- which has checksums, too. Also, one may assume that the attacker knows "something" of the data (otherwise, why would he bother cracking it at all ?). – Thomas Pornin May 07 '11 at 21:07
  • @Mukul: there is no 32-bit AES; it is defined with key sizes 128, 192 and 256 bits only. Also, a passphrase is often the weakest link but it is possible to have a strong passphrase (you just have to make a memory _effort_). A 128-bit key for AES ensures that the key length will not be a weak point at all. – Thomas Pornin May 09 '11 at 15:38
  • OK, that was a bad example - there is no 32-bit AES, I've changed it to be accurate. But my point is, what contribution does key length have to the encryption if all that's needed to break it is a dictionary attack on the passphrase? It seems like key length isn't really important. – Mukul May 09 '11 at 16:04

3 Answers3

9

Yes, when using symmetric encryption with a key derived from a password, then the result in inherently subject to exhaustive search on the possible passwords, also known as "dictionary attacks". GnuPG includes the usual deterrents, namely salts (so that the attack cannot be optimized through precomputed tables) and a slow key derivation function (with thousands of internal iterations). Security still resides on the password entropy. The GnuPG documentation uses the term "passphrase" to underline the need for high password entropy (very long passwords -- in particular passwords consisting of several "words" -- tend to have high entropy).

Whether a given encryption system is deemed strong enough for US classified documents is defined by some arcane federal regulations which would never give a generic blessing on a mere algorithm description in any case. AES is, per se, an "approved" algorithm, but an actual encryption system may be "approved" only if it is an "approved" implementation of an "approved" algorithm. As far as I know, GnuPG is unlikely to be so approved, especially since it was mainly written in Germany (but, with opensource projects, you cannot really know from where the code comes -- and that's a big issue for people who "approve" implementations).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Is this documented somewhere? I tried searching the man page for key derivation options or even information on the default scheme, but could not find anything... – static_rtti Feb 19 '15 at 08:57
  • Search for "s2k" in the GnuPG man page. For the specification, see [RFC 4880](http://tools.ietf.org/html/rfc4880#section-3.7). – Thomas Pornin Feb 19 '15 at 11:20
4

Any encryption that only needs a passphrase to decrypt can only be as strong as that passphrase itself. This is why gnupg has that public and private key stuff in.

If you use your cat's name as passphrase then it might be guessed; but I wish you good luck if the passphrase is 512 bytes of /dev/random. That's why some frontends try to check the "strength" of a password. KCryptography is like a chain - only as strong as the weakest link.

Turbo J
  • 149
  • 2
0

For your updated question: 192-bit AES is not measurably stronger than 128-bit AES with or without a passphrase - the AES aspects of both are out of reach for the foreseeable future even given Moore's law, unless you are worried about the possibility of quantum computing attacks. Is someone out there claiming that it is? Don't fall for it.

Don't interpret the US requirements as approving weak passphrases so long as you use AES-192. Each part of a cryptosystem is important, and key management (passphrases) is among the toughest parts.

The previous answers already address the fact that a passphrase is often the weakest link, and there are alternatives to it.

nealmcb
  • 20,544
  • 6
  • 69
  • 116