I have not read the paper in detail, but I agree with the high level conclusions. If it were not for quantum computers, I think IETF should move to curve25519 as quickly as possible. With quantum computers the picture is more complicated as ECC would anyway need to be replaced with PQC in the not to distant future.
Cheers, John On 19/10/16 09:36, "n.mavrogiannopou...@gmail.com on behalf of Nikos Mavrogiannopoulos" <n.mavrogiannopou...@gmail.com on behalf of n...@gnutls.org> wrote: >On Tue, Oct 18, 2016 at 8:46 PM, John Mattsson ><john.matts...@ericsson.com> wrote: >> New paper “Measuring small subgroup attacks against Diffie-Hellman” >> https://eprint.iacr.org/2016/995.pdf >> “Cryptographic recommendations from standards committees are often too >> weak or vague” >> “However, the tangle of RFCs and standards attempting to define current >> best practices in key generation and parameter sizing do not paint a >>clear >> picture, and instead describe complex combinations of approaches and >> parameters, exposing the fragility of the cryptographic ecosystem. As a >> result, developers often forget or ignore edge cases, leaving many >> implementations of Diffie-Hellman too close to vulnerable" >> >> “As we show in this paper, finite-field based Diffie-Hellman has many >>edge >> cases that make its correct use difficult, and which occasionally arise >>as >> bugs at the protocol level.” >> >> “As a concrete recommendation, modern Diffie-Hellman implementations >> should prefer elliptic curve groups over safe curves with proper point >> validation.” > >I am not sure that the recommendations of this paper should be blindly >trusted. There are some inaccurate facts about a library I work on >[0], but a part of the abstract is also concerning: >"We examine over 20 open-source cryptographic libraries and >applications and observe that until January 2016, not a single one >validated subgroup orders by default." > >That's objectively accurate, but the authors do not attempt to find >out the actual issue behind it. Are all implementations bad, or there >are obstacles in doing that? I am aware that TLS client >implementations do not validate subgroup orders by default, because >the group information provided by TLS is not sufficient to validate >the subgroup order. It is simply impossible for them to do any >validation. > >regards, >Nikos > >[0]. >https://lists.gnupg.org/pipermail/gnutls-devel/2016-October/008198.html _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
