Security doubts on 3DES default

[Ryru]

Thank you Robert for your response and point of view.

On 03/13/2017 04:17 PM, Robert J. Hansen wrote:
>> 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.

Just because it's required behaviour doesn't mean it's (still) good. ;-)
But I will try contact them.

Apart from that, as GnuPG is in a kind of symbiosis with
OpenPGP/RFC4880, I think it's important to discuss this on this mailing
list (as well).

>> 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.

I agree with you, we have better options than 3DES so we should switch
to better ciphers as soon as possible.

> 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.

I think it's a question of time till 3DES is broken, like it was with
SHA-1. To be at least one step ahead of such a mess should be the goal.

> 
>> What are your thoughts about this behaviour?
> 
> Take it up with the IETF OpenPGP working group, not GnuPG.  Get them to
> change the RFC.

As mentioned, I'll try to reach them. The support from the GnuPG
community, on this topic, would be appreciated.

>  
>> 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.)

Where have you found this information? I only found this draft[0] which
still contains 3DES and SHA-1.

Thanks in advance and best regards
Pascal

[0] https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-01