RE: Diffie-Hellman question

When you look at the parameters for DH, you end up with two different sets
of parameters that are presented.

 

Set #1 - These are the parameters that required to do the DH math itself.

Set #2 - These are the additional parameters that are needed to check that
the first set of parameters were not generated in such a way as to allow for
easy attacks.  (For example, RFC 2785 small subgroup attacks on DH in
S/MIME).

 

The security nerds like me will always say that, unless you have outside
verification, you should only import and accept a full set of parameters and
you should do the validation at that point.  If you validate a DSS signature
on a set of parameters with a small group, you have not really done the
validation correctly.

 

I would have  strong personal preference to only allow for parameters to be
specified in terms of X9.42 and not allow for them to be done in PKCS#3.
There are too many known security holes to drive through otherwise.

 

Another question is - should the underlying system be able to generate a new
set of parameters if none are give?

 

From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: Friday, February 21, 2014 10:41 AM
To: public-webcrypto@w3.org
Subject: Diffie-Hellman question

 

All,

 

The DH section includes the note:

 

"TODO: This interface is broken for import/export. Generate is defined in
terms of PKCS#3 - meaning it takes base/g and prime/p - whereas the
dhpublicnumber used by X.509/RFC 3279 uses the X9.42 form - meaning it takes
base/g, prime/p, and subprime/q. The inconsistency here needs to be resolved
before this can be reliably implemented."

 

Two things are not clear to me after reviewing PKCS#3, RFC3279 and X.9.42.

 

First, in what context do we need to support export of domain parameters in
WebCrypto ? Export of the public key of the generated pair presumably
obtains us the public value and the only appropriate key format is "raw" (or
is there standard serialization from X.509?). Export of the private key of
the generate key pair would presumably export the private value (referred to
as x in PKCS#3) again with "raw" being the only appropriate format. In all
cases the domain parameters are available as explicit members of the
key.algorithm interface.

 

[JLS]  I am not sure that "raw" makes any degree of sense for any asymmetric
key pair.  Having the private or public value, without also having the rest
of the public parameters make those values both meaningless and prone to
error.  You do not want to use a private value generated with parameter set
A used in another context with parameter set B.

 

 

I can export a private as a PKCS#8 or a JWK.  I can export a public as an
SPKI or a JWK.  In neither case does export (or import) as raw many any
sense because it is not fully specified.

 

Second, it seems that the parameter q is not necessary for DH. But, without
the input parameter, m, in X.9.42 (which determines the size of q, which in
turn is the order of g), there is no way to specify the required strength of
the private key. It is not necessary for both parties to use the same value
of q for DH or to know which value the other party used, so it is not clear
to me why it is included in the X.9.42 domain parameters, except for the
other algorithm described there, MVQ, or for ensuring that both parties use
private values of similar strength (or for some form of validation?).

 

Can anyone help me here ? I think the above note is probably not an issue,
but we need to determine whether we should support an input, m, to generate
a private key of a specified strength (IIUC). I'd be interested to know what
the common libraries support.

 

...Mark