Hi!
The Logjam paper (https://weakdh.org/) makes three recommendations for
Diffie-Hellman parameters: transition to ECC-DH, use larger (>=2048
bits) DH primes, and avoid fixed 1024-bits DH primes.
In reviewing the current standardized DH parameters, I came across two
questions.
First some references with an historical perspective.
Oakley primes were introduced in RFC2409 section 6 (768 and 1024 bits).
Larger primes were standardized in RFC3526 (confirmed widely used 1536
bits plus 2048, 3072, 4096, 6144, and 8192 bits). The DH generator is 2.
Very recently
(https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
appendix A) the Oakley prime number generation strategy is replayed,
substituting the Euler constant binary extension for the pi binary
extension as an unbiased trusted pseudo-random sequence. Note that the
DH generator remains at 2 in this new document.
In the meantime, two standardization actions took place.
The authors of an EAP variant RFC6124 (section 7.1) found useful to
modify the Oakley standard parameters by changing the DH generator value
from 2 to a small prime number specific to each DH prime number
(respectively 5, 31, 11, 5, and 5 for Oakley primes of 1024, 1536, 2048,
3072, and 4096).
Finally, RFC5114 seems to scoop NIST on its own ground, introducing DH
parameter sets with a defined and reduced size "prime order subgroup"
with a generator value as large as the DH prime. I wonder if this
standardization action actually turned a test vector example (originally
intended as an example of a random parameter generation) into a fixed DH
parameter set of the type found problematic in the Logjam paper. Indeed,
the RFC5114 text refers to the NIST CSRC page
http://csrc.nist.gov/groups/ST/toolkit/examples.html from which one may
come to the document
http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/KS_FFC_All.pdf
which is over 100 pages of test data without textual explanations or
author attribution.
Then the two questions:
Q.1 Is the generator value selection per RFC6124 a better alternative
than the fixed generator value 2?
Q.2 Is there any benefit in the size reduction for the prime order
subgroup standardized by RFC5114 (beyond complying to the NIST addiction
to cryptographic parameters exactly fit to a given security parameter)?
Conclusion
The default answers are yes to Q.1 and no to Q.2. Therefore, ongoing
standardization work is a dubious place for basic wisdom on using a
cryptographic primitive. RFC6124 has it almost right (it should have
omitted the 1024 prime size) but seems outside of mainstream IETF work.
Apologies to IETF'ers for not making a contribution out of my opinion
(you may use this message as you see fit).
Thanks in advance for comments!
- Thierry Moreau
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
