Re: Diffie-Hellman question

Ok, so SubjectPublicKeyInfo import/export will work with the PKCS#3 OID.

- Should we name this algorithm "DH-PKCS3" ?
- Should the DhKeyGenParams include the privateValueLength optional field ?

...Mark


On Mon, Feb 24, 2014 at 11:45 AM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Mon, Feb 24, 2014 at 11:11 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>> Ryan,
>>
>> I'm not sure exactly what you're suggesting. The workflow you describe is
>> the obvious one if SPKI import/export is supported and, yes, we could
>> change the public property of DhKeyDeriveParams to be a Key and this would
>> make this flow slightly less weird.
>>
>> Are you suggesting we simply support X9.42 instead of PKCS#3 ? You
>> mention there is a lack of library support for X9.42. If, instead, we
>> implement this workflow with PKCS#3 it seems not obvious that this would
>> work when talking to a X9.42 endpoint which expects us to provide and pay
>> attention to the q parameter.
>>
>
>> If we stick with PKCS#3 and raw import / export you can certainly build a
>> DH key exchange - you just need to use your own format for communication of
>> the p / g parameters.
>>
>> ...Mark
>>
>>
> All of the libraries mentioned support X9.42 import. It's only an issue
> when generating a key / domain parameters with q.
>
> The questions on this:
> - Is X9.42 import widely implemented? Yes
> - Is X9.42 export widely implemented? No. PKCS#11 only.
> - Is X9.42 generation widely implemented? No
> - Is PKCS#3 import widely implemented? Mostly, yes (Apple not-withstanding)
> - Is PKCS#3 export widely implemented? Yes.
> - Is PKCS#3 generation widely implemented? Yes.
>
> It appears that I missed the bit from PKCS#3 that defines the OID of
> dhKeyAgreement (1.2.840.113549.1.3.1) , rather than using the RFC 3279
> dhpublickey OID (1.2.840.10046.2.1). With dhKeyAgreement, it aligns with
> what CAPI/CNG/OpenSSL/NSS support - namely, the following ASN.1 structure
>
> DHParameter ::= SEQUENCE {
>   prime INTEGER, -- p
>   base INTEGER, -- g
>   privateValueLength INTEGER OPTIONAL }
>
> The small subgroup attack that Jim raised is not an issue for ephemeral
> negotiations, AIUI. As such, I think there is still value in supporting
> PKCS#3 only.
>
> Note that OpenSSL doesn't support X9.42 until 1.0.2-Beta-1 (and it's still
> experimental).
>
> Seems like we can resolve all issues here as PKCS#3 only, no custom
> formats.
>