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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
