Re: inconsistent references for HKDF-CTR

[adding back the list]


On Thu, Feb 27, 2014 at 1:19 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> The combination of 108 and 56C still has gaps
>
>
>
> 800-56C says the following about Length
>
>
>
> length of the binary string [L]2 is specified by the encoding method for
> the input data. (L is equivalent to "keydatalen" in the single-step key
> derivation functions defined in NIST SP 800-56A [1] and to "Kbits" in the
> single-step key derivation functions defined in NIST SP 800-56B [2].)
>
>
>
> This means that without an additional document, you don't know what the
> length of [L] is, or how the pieces are going to be put together.
>

That makes things very awkward from a WebCrypto perspective if the idea is
that one could build some existing protocols in Javascript using these
WebCrypto primitive. We would need to know about existing applications of
this key derivation function and the lengths of [L]2 that they used so that
we would know which length or lengths to support in WebCrypto.

Of course if there are no existing protocols that use this, and we are
specifying it for future use only, then we can just choose a value
ourselves.

...Mark




>
>
>
>
> You are very correct when you say that these are different algorithms.
> None of the versions in 108 match the version in the RFC.  I was just
> noting that the bit at the start - that is the key extraction step - is the
> same for both.
>
>
>
>
>
>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Thursday, February 27, 2014 12:26 PM
> *To:* Jim Schaad
> *Subject:* Re: inconsistent references for HKDF-CTR
>
>
>
> We refer also to 800-56C. Is the combination of 800-108 and 800-56C
> unambiguous ? Or are there still gaps.
>
>
>
> I assume from your reply that I am right that these specify a different
> algorithm from the RFC.
>
>
>
> ...Mark
>
>
>
> On Thu, Feb 27, 2014 at 11:53 AM, Jim Schaad <ietf@augustcellars.com>
> wrote:
>
> First, I will note that both of the algorithms do the Key Extraction step.
> So both of the algorithms will compute
>
> PRK = HMAC-HASH(s, ZZ)
>
> So that portion of the two algorithms is not any different.
>
> I will note that RFC 5869 is complete and has test vectors, however
> SP800-108 does not specify how the encoding of P is to be done.  Thus item
> such as the length of [L] is not specified by the document.
>
> I can implement 5869, I can't do that for SP800-108 without a couple of
> additional items being specified.  You end up needing some additional data
> such as is provided in section 5.9 of SP 800-56B (ASN.1 or concatenation
> encoding of the input).
>
> Jim
>
>
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: Thursday, February 27, 2014 10:00 AM
> To: public-webcrypto@w3.org
> Subject: inconsistent references for HKDF-CTR
>
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24838
>
> HKDF-CTR references RFC5869, NIST SP800-56C and NIST SP800-108.
>
> These references specify different algorithms.
>
> RFC5869 calculates output keying material as the concatenation of T(i) i=1,
> ..., N where T(i) = HMAC-Hash(PRK, T(i-1) | info | [i] ) where PRK is a key
> derived from the base key through an extraction step and [i] is a single
> octet representation of i.
>
> By contrast, SP800-108 calculates the output keying material as the
> concatenation of K(i) i=1,...,N where K(i) := PRF(KI, [i] || Label || 0x00
> || Context || [L] ) where KI is the key derivation key and [L] is the
> binary
> representation of the number of output bits.
>
> Which reference should we use, or should we support both as separate
> algorithms ?
> ...Mark
>
>
>