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)

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.