RE: FW: Renaming of HKDF-CTR to HKDF

 

 

From: Eric Roman [mailto:ericroman@google.com] 
Sent: Tuesday, March 08, 2016 8:25 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: public-webcrypto@w3.org
Subject: Re: FW: Renaming of HKDF-CTR to HKDF

 

Chrome's HKDF implementation requires the parameter to be specified.

 

Depending how we update the spec per bug 27425, I can modify Chrome to match.

 

Regarding making the salt/info parameters for HKDF optional in the WebCrypto spec:

 

(a)   RFC 5869 describes "salt" as being optional (not needing to be specified), but "info" is described as being "optional" in the sense it can be 0-length. So if the intent is to exactly match RFC 5869's wording then I expect we want to leave "info" as a required parameter.

I agree – I just feel that it is slightly easier to specify either null or absence than a zero length buffer.

 

  (b) A 0-length salt in the case of HKDF is the same as an unspecified salt -- because the HMAC will zero-pads its key up to HashLen. So "omitting salt" is equivalent to just passing an empty salt using our API AFAICT.

 

(b)  Not specifying a salt is a poor practice anyway. From the perspective of our WebCrypto API, having it be optional isn't going to be doing our users any favors in ease of use, in my opinion. If it is mandatory then accidentally forgetting it raises an error. And if you really do want to use the default you can easily pass an empty BufferSource.

 

No this is not true.  If one is doing ephemeral-ephemeral or ephemeral-static (EC)DH then neither the salt or the info fields are required.  The input keying material is going to be unique so the output is also going to be unique.  This is assuming that you are not trying to derive two different things such as a key and an IV from this.  Many of the documents specify that salt and/or info are needed only for the case of static-static ECHD or for performing a KDF from a good shared secret.

 

  (d) Pbkdf2Params similarly has a "salt" parameter that is currently required. They are different algorithms, but from the perspective of an API consumer it feels weird for salt to be mandatory in one but not the other, when we could just as easily have defined an omitted "salt" to be equivalent to empty BufferSource for both. From an internal consistency perspective if we choose to make HKDF's salt optional, we should consider whether PBKDF2's salt should similarly be optional.

 

Yes – but in this case the salt is actually a required field by the algorithm so the cases are not completely parallel.

 

I can appreciate trying to directly match RFC 5869's wording, but my current inclination would be to leave "salt" as required when adding HKDF's definition to our spec.

 

All of the above said, I don’t have any problems with making the salt and the info as required.  It might be nice to change the type to BufferSource or null to make code slightly easier.

 

Jim

 

On Tue, Mar 8, 2016 at 6:13 PM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:

Yes that fixes all of my problems but one.  If the salt is missing, I am doing this by not providing the parameter rather than providing a zero length array of bytes.  It seems to me to be a reasonable way of doing this but is not the same as what the previous IDL did.

 

Opinions?

 

Jim

 

 

From: Eric Roman [mailto:ericroman@google.com <mailto:ericroman@google.com> ] 
Sent: Tuesday, March 08, 2016 2:57 PM
To: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >
Cc: public-webcrypto@w3.org <mailto:public-webcrypto@w3.org> 
Subject: Re: FW: Renaming of HKDF-CTR to HKDF

 

I haven't run the tests, but looking at your code in:

https://github.com/jimsch/web-platform-tests/blob/HKDF/WebCryptoAPI/HKDF_derivebits_known.js

 

I believe the problem is simply a typo: "Hash" instead of "hash".

 

(The test runner expects "hash", but the SHA1 tests and empty salt/info are naming it "Hash").

 

On Tue, Mar 8, 2016 at 2:20 PM, Eric Roman <ericroman@google.com <mailto:ericroman@google.com> > wrote:

 

 

On Mon, Mar 7, 2016 at 5:56 PM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:



> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com <mailto:ietf@augustcellars.com> ]
> Sent: Monday, March 07, 2016 4:46 PM
> To: 'public-webcrypto@w3.org <mailto:public-webcrypto@w3.org> ' <public-webcrypto@w3.org <mailto:public-webcrypto@w3.org> >
> Subject: RE: Renaming of HKDF-CTR to HKDF
>
> For the curious, here is a set of known value tests based on both the
edits and
> RFC 5869
>
> https://github.com/jimsch/web-platform-tests/tree/HKDF
>
> The version of Chrome that I am running does not appear to support
>       SHA-1
>       Zero length salt and info

 

Can you provide some specific examples of the failures?

 

According to Chrome's testing it supports SHA1 and empty salt/info.

For instance these tests exercise those options:

 

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/crypto/subtle/hkdf/deriveBits-rfc5869-test-vectors.html

 

>
> The version of Firefox that I am running fails all of the tests.
>
> Jim

>
> > -----Original Message-----
> > From: Jim Schaad [mailto:ietf@augustcellars.com <mailto:ietf@augustcellars.com> ]
> > Sent: Monday, March 07, 2016 3:35 PM
> > To: public-webcrypto@w3.org <mailto:public-webcrypto@w3.org> 
> > Subject: Renaming of HKDF-CTR to HKDF
> >
> > I have done the pull request that I promised on today's conference
> > call. It can be found at:
> > https://github.com/w3c/webcrypto/pull/16
> >
> > I believe that this correspond to what Rob said that Mozilla has
implemented.
> > Please review and comment on the field names.
> >
> > Additional issues that can be addressed here:
> >
> > 1.  HKDF allows for salt to be optional, there is a bug reported by
> > Harry
> > (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27473)  which says
> > that this may be a problem.  I do not know if this was reported for
> > the NIST version or for the IETF version of the algorithm.  It may be
> > that it is just fixed by switching algorithms.  If not then we can
> > modify the text to provide default salt behavior in the algorithm
description.
> >
> > 2.  I did not address the question of having an export function for
> > KDF functions
> > (27774) as it should be done for all of the KDF functions at the same
time.
> > However I would support doing this.
> >
> > Jim
> >
> >