Re: Diffie-Hellman question

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




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

>
>
>
> On Mon, Feb 24, 2014 at 10:06 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>> So, if the libraries people are using to implement WebCrypto right now
>> support only PKCS#3, shouldn't we stick with that for this first version ?
>> Just as we have "RSASSA-PKCS1-v1_5" we could have "DH-PKCS3" and later
>> introduce X9.42.
>>
>> That would mean that in this version we would not be able to support
>> export except in raw format. I would then suggest that we support import
>> only in that format too. It's not quite clear what import is for, though,
>> except perhaps to enable use of the DH Phase II primitive with a private
>> value generated some way other than deriveKey: we would need a
>> DhImportParams dictionary to provide the prime and generator. Importing a
>> DH public key is useless, because the only think a Key object representing
>> a DH public key can be used for is to export the Public Value.
>>
>> ...Mark
>>
>>
>>
>
> I'm going to have to disagree with your conclusions. If we were to adopt
> your proposal, I would see us not being able to implement DH, because
> there's no hope of developing anything useful.
>
> As Jim explained, you can 'downcast' from X9.42 to PKCS#3, but not
> 'upcast'. While the small subgroups is a concern, I don't believe it shares
> the same concern when using pre-negotiated parameters.
>
> Regarding the import / phase 2 issue, you're correct in highlighting
> there's an issue, but again I'm not sure I'd agree to the same conclusions.
> We need to solve the asymmetry here with import, and I suspect that
> DhKeyDeriveParams is using the wrong type by taking "public" as a
> BigInteger.
>
> Namely, if you want to do a DH-Static negotiation, where the peer supplies
> their expected parameters as a SubjectPublicKeyInfo, the ideal workflow
> would be something akin to (with asynchronicity elided)
>
> // Import, not knowing of the parameter space for which the key will be
> negotiated
> otherPubKey = importKey("spki", ...)
> // Generate a key to the peers' parameter space
> keyPair = generateKey({ name: "DH", prime: otherPubKey.prime,
> generator: otherPubKey.generator }, ...);
> // Grab our key in SPKI. Could just as well be 'raw' since the parameters
> are duplicated with the peers
> ourRawKey = exportKey("spki", keyPair.publicKey);
> // Grab the 'raw' key. This is the 'weirdness' of the DhKeyDeriveParams
> issue
> otherRawKey = exportKey("raw", otherPubKey);
> // Derive a shared secret
> secret = deriveKey({name: "DH", public: otherRawKey }, keyPair.privateKey,
> { name: "AES-CBC", length: 128 }, false, ['encrypt']);
>
> // Allows peer to compute |secret|
> send(ourRawKey);
>
> // Encrypts dataToProtect under |secret|
> send(encrypt({name: 'AES-CBC', iv: ...}, dataToProtect));
>