Re: [CFRG] HKDF - difference in counter between original paper and RFC 5869

Good question. I believe (I checked some old email of mine with Pasi) this
was done for compatibility with the definition of HKDF in IKE (which is
when I originally designed HKDF,  though without a name and published
analysis). I wasn't too happy about being limited by backwards
compatibility but it was judged at the time as one less hurdle for adoption.

Hugo

On Tue, May 31, 2022 at 9:33 AM Neil Madden <neil.e.madden@gmail.com> wrote:

> When looking at HKDF I was curious why the definition of HKDF-Expand in
> RFC 5869 [1] starts the counter at 1 rather than 0:
>
>    T(0) = empty string (zero length)
>    T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
>    T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
>    T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
>    ...
>
>
> Section 4.2 of the original paper [2] does indeed start the counter value
> at 0:
>
> PRK = HMAC(XTS, SKM)
> K(1) = HMAC(PRK, CTXinfo ∥ 0),
>
> K(i+1) = HMAC(PRK, K(i)∥CTXinfo∥i), 1≤i<t,
>
> I can’t find any rationale for why this change was made in the RFC, so I
> thought I’d check here in case anyone knows? Given that the counter is only
> a single byte, eliminating one of the 256 valid values seems unfortunate. I
> also can’t see any security or practical reason for doing so, but perhaps
> I’m missing something?
>
> (It happens to be a useful feature for me, but I suspect not deliberately
> so: a C program I am looking at uses HMAC and happens to include a null
> terminator byte in each input. It is therefore accidentally
> domain-separated from use of HKDF-Expand, potentially providing a
> satisfyingly simple way to upgrade it to AEAD by deriving a separate
> encryption sub-key. But this inclusion of a null-terminator byte appears to
> not be deliberate).
>
> [1]: https://www.rfc-editor.org/rfc/rfc5869#section-2.3
> [2]: https://eprint.iacr.org/2010/264.pdf
>
> Best wishes,
>
> Neil
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>