[cryptography] Diffie-Hellman after the Logjam paper versus IETF RFCs ...

Thierry Moreau thierry.moreau at connotech.com
Wed Nov 18 08:21:16 EST 2015


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 

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 (
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
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)?


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

More information about the cryptography mailing list