Security doubts on 3DES default
ryru at addere.ch
Tue Mar 14 21:25:47 CET 2017
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.
>> someone, knowingly or not, removed all his/her symmetric encryption
>> algorithms in his/her public key, our conversation would only be 3DES
> 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
>> 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 which
still contains 3DES and SHA-1.
Thanks in advance and best regards
More information about the Gnupg-users