Security doubts on 3DES default

[Robert J. Hansen]

> According to the gpg2 man page, 3DES is added always as kind of least
> common denominator:

This is required behavior per RFC4880.  Your concern should be addressed to
the IETF OpenPGP working group, not to GnuPG.

> In my opinion this design decision can lead to serious security troubles.
If
> someone, knowingly or not, removed all his/her symmetric encryption
> algorithms in his/her public key, our conversation would only be 3DES
> encrypted.

There is no security risk with 3DES unless you (foolishly) choose to encrypt
vast quantities of data (multiple gigabytes) with the same key.

RFC4880 requires 3DES be used with three independent subkeys, giving it a
technical keyspace of 192 bits, the same as AES192.  However, 24 of those
bits are used for parity and contribute nothing to the security of the
system, meaning it comes in at 168 bits of effective key.  This is a
keyspace about a trillion times larger than AES128's.

There are a couple of *theoretical* attacks on 3DES that reduce it to about
a "mere" 112 bits (still unassailable, but less strong than we'd like).  The
best known attack requires a billion known plaintexts and
100,000,000,000,000,000 gigabytes of RAM.

3DES is even somewhat resistant to quantum computation, as a 168-bit
keyspace is still an 84-bit keyspace even after hitting it with Grover's
algorithm and a large quantum computer.  An 84-bit keyspace can be
brute-forced by people willing to throw huge amounts of resources at the
problem, but it'd be tremendously annoying.  A few years ago when
distributed.net tackled RC5-64 (with a keyspace a millionth the size of a
quantum-attacked 3DES) it took them a large distributed cracking effort and
eighteen months of time.

I don't know who told you that 3DES was insecure.  They misled you.  It is
not insecure.  It is slow, it is ungainly, it has all the aesthetics of a
Soviet worker's housing bloc, and we have better ciphers available to us.

But 3DES has also been turning brilliant cryptanalysts into burned-out
alcoholic wrecks for 40 years.

> I think the same goes for the hashing algorithm SHA1.

Again, required per the spec, and this can be prevented by having one person
on the list use a DSA-2048/-3072 key, which forbids SHA-1 usage.

> Is my understanding correct or do I miss an important fact?

You're missing the boat on the security of 3DES.  You're correct that SHA-1
is unsuitable for use as a hashing algorithm and that usage of it may be
mandated in certain situations.

> What are your thoughts about this behaviour?

Take it up with the IETF OpenPGP working group, not GnuPG.  Get them to
change the RFC.
 
> Wouldn't it be great to raise the minimum encryption and hashing level to
a
> more secure cipher?

The current opinion in the IETF OpenPGP working group is the next iteration
of the standard will probably settle on AES256 and SHA256 as replacement
MUSTs for the current 3DES/SHA-1.  (Other hashes, such as BLAKE2, SHA512,
and SHA-3/Keccak, are also being discussed as optionals.)

However, when this next iteration will be released is anyone's guess.  The
group works painfully slowly.