[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FIPS 186 and X9.42: One of these things is not like the other
- To: "John C. Kennedy" <jkennedy@trustpoint.com>
- Subject: Re: FIPS 186 and X9.42: One of these things is not like the other
- From: Ben Laurie <ben@algroup.co.uk>
- Date: Sun, 21 Nov 1999 10:44:17 +0000
- CC: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, djohnson@certicom.com, wpolk@nist.gov, housley@spyrus.com, jis@mit.edu, mleech@nortelnetworks.com
- Organization: A.L. Group plc
- References: <NDBBKGCMPJCKIDPKAHACIENDCAAA.jkennedy@trustpoint.com>
- Sender: owner-ipsec@lists.tislabs.com
"John C. Kennedy" wrote:
> (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
> DomainParameters ::= SEQUENCE {
> p INTEGER, -- odd prime, p=jq +1
> g INTEGER, -- generator, g
> q INTEGER, -- factor of p-1
> j INTEGER OPTIONAL, -- subgroup factor
> validationParms ValidationParms OPTIONAL }
I was perusing the OpenSSL DH code recently, and I noticed that DH was
using a Germain prime for p (miscommented as a strong prime, btw),
which, of course, makes j=2. But q and j are not kept - what are they
actually used for? (Answers in the form "read XXX" are welcome)
BTW, why the redundancy? If you have any two of p, j and q, you don't
need the other, and surely the work involved to recover the third one is
minimal in comparison to anything else you'd need to do, sumswise?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Follow-Ups:
References: