Re: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again)

[John Mattsson <[e-mail]>]

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

/John


On 18/10/16 16:47, "IPsec on behalf of Stephen Kent"
<[e-mail] on behalf of [e-mail]> wrote:

>Paul,
>
>It's  been over 8 years since this RFC was published, and I have not
>looked at it since then. My recollection is that we wrote 5114 because
>an IPsec developer approached me and said that he wanted to support
>these groups in a product. He said that he wanted test vectors for the
>groups, consistent with what we have done for many other algs. I
>persuaded Matt to generate the RFC because it was a relatively easy task
>a good way for Matt to get acquainted with the RFC process.
>
>As to your question, I have no info about how the NIST DH values were
>generated. However, I do agree with Yoav and Tero that it seems unduly
>prejudicial to declare these to be a MUST NOT. The fact that one can
>generate trap-doored DH values that cannot be detected is not the same
>as having proof that a given set of values have been generated in that
>fashion. Moreover, if one interprets a MUST NOT in this context to mean
>that an implementation supporting any of these groups is non-compliant,
>then that unfairly penalizes existing implementations, as Tero noted.
>Moreover, if the concern raised by the paper (which I have read) is with
>MODP groups of size 1024 (or smaller), only 1 of the groups in 5114 fits
>that criteria (section 2.1).
>
>I have not tracked the status of these NIST groups re evaluation
>criteria like FIPS 140-2. If these groups are approved for use in
>products evaluated under that FIPS (I don't know if they are),
>deprecating them creates a possible conundrum for vendors who want to
>comply with RFCs and with FIPS evaluation criteria. Thus I suggest a
>less dramatic response than declaring all of the groups in 5114 to be
>MUST NOT.
>
>I'm not a vendor of any crypto products (these days), and I've never
>been a crypto mathematician. So my views are based only on what I recall
>about the creation of 5114 and about IETF crytpo standards practices in
>general.
>
>Steve
>
>_______________________________________________
>IPsec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ipsec