RE: inconsistent references for HKDF-CTR

In order to have done this implementation there a set of decisions that must
have been made.  I would have no problems with documenting these decisions
as part of the description of the algorithm in our specification, however
they do need to be specified.

I am going to assume that the decisions you made are:

1. We are saying that this is the KDF in Counter Mode that is defined in
section 5.1 of SP800-108.  All of the modes defined here are counter modes
so we need to be specific.
2.  I don't know if you implemented the Key Expansion function which is
required by SP800-56C, but is not documented in SP800-108.
3. The value to be process is formed by simple concatenation and not by
something like ASN.1 encoding
4. The lengths of i and L are one byte
5. Label is either a binary string (as you suggest below) or a UTF8 encoded
string.  In all cases it does not encode a trailing zero as that is supplied
by the encoding function.  There is a restriction that needs to be imposed
if we say that Label is a binary array.  Specifically it cannot include a
zero byte.

Jim


> -----Original Message-----
> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
> Sent: Thursday, February 27, 2014 12:59 PM
> To: Jim Schaad; 'Mark Watson'; public-webcrypto@w3.org
> Subject: RE: inconsistent references for HKDF-CTR
> 
> From an editorial perspective, I think if you are calling it HKDF-CTR then
you
> need to refer to RFC 5869 since that is what uses the HKDF name.
> 
> However, as an implementer, we do have SP800-108 implemented in the
> platform and currently no implementation of HKDF. So I would prefer the
> former to be standardized since it is also potentially a little faster
(HKDF is like
> the SP800-108 feedback mode in that the HMAC invocations are serialized).
> 
> SP800-108 specifies the Label and Context as binary strings (section 7.4).
So I
> think we should ask for these parameters to be supplied as base64 to avoid
> the encoding issue that Jim points out.
> 
> It seems to me that SP800-56C is at best an informational reference here.
It
> defines a general way of thinking about KDFs that includes RFC 5869 and
> SP800-108 but defers to those documents for specific realizations.
> 
> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: Thursday, February 27, 2014 11:53 AM
> To: 'Mark Watson'; public-webcrypto@w3.org
> Subject: RE: inconsistent references for HKDF-CTR
> 
> 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

Received on Thursday, 27 February 2014 22:25:16 UTC