RE: Diffie-Hellman question

 

 

From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Friday, February 21, 2014 11:16 AM
To: Mark Watson
Cc: public-webcrypto@w3.org
Subject: Re: Diffie-Hellman question

 

 

 

On Fri, Feb 21, 2014 at 10:40 AM, Mark Watson <watsonm@netflix.com> wrote:

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

 

I'm not sure how you reached "raw" being the only appropriate format after reading RFC3279 Section 2.3.3

 

First, recall that:

 

SubjectPublicKeyInfo  ::=  SEQUENCE  {
     algorithm            AlgorithmIdentifier,
     subjectPublicKey     BIT STRING  }

AlgorithmIdentifier ::= SEQUENCE {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }  

 

Section 2.3.3 dictates that this looks like

 

SubjectPublicKeyInfo = {

  algorithm: {

    algorithm: dhpublicnumber,

    params: {

      p: <some_value>,

      g: <some_value>,

      q: <some value>,

      j: (optional),

      validationParams: (optional){

        seed: <some_value>,

        pgenCounter: <some_value>

      },

    },

    subjectPublicKey: <DH public value as integer>

}

 

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.

 

Again, no. PrivateKeyInfo is a valid format here.

 

 

Second, it seems that the parameter q is not necessary for DH.

 

It is for X9.42. It's not for PKCS#3.

 

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

 

 

PKCS#11 - makes a distinction between PKCS#3 and X9.42. See Section 6.4 of http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-30m1-d7.pdf

  PKCS#3 public keys - p, g, y

  PKCS#3 private keys - p, g, x, (length in bits of X)

  X9.42 public keys - p (>= 1024 bits, in steps of 256), g, q (>= 160 bits), y

  X9.42 private keys -= p, g, q, x

 

CNG - Only supports PKCS#3 ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx )

 

[JLS] Once again Microsoft has demonstrated that it has not real security people in the cryptographic division of the company.   I am always frustrated by the number of problems that it has.   However I would note that for DSA it did get it right.

 

Also it is easy to go from X9.42 to PKCS #3, but the other direction is impossible.

 

OS X Common Crypto - PKCS#3 (as of 10.8) (although it doesn't actually support import/export of params yet)

 

The point being that all the APIs support PKCS#3, whereas all the useful-for-certificate bits expect inputs/outputs in the form of X9.42

 

Hence why I added that TODO.