From nobody Thu Jun 2 00:38:23 2022 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000E4C157908 for ; Thu, 2 Jun 2022 00:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjPdKiWOw4NI for ; Thu, 2 Jun 2022 00:38:17 -0700 (PDT) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D91BC14F725 for ; Thu, 2 Jun 2022 00:38:17 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id k19so5295846wrd.8 for ; Thu, 02 Jun 2022 00:38:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NC5ZljUpQm7fhnbui/YtAkjdJALM3dk67eINfdnYiAs=; b=nMP6NCjPL5/X3VaSwx+/NZ8rUwcJNio0kAqu+Fio7wGktQa6QcDxpugW13+dhaxA/G H+hpPYRJH/nWurvK70wZZwQQh87qo9SH8dcJpRFXz9c5b8lWKAgHL9/FFdn9PmRGmTk2 gUNoafZARAXcaCleriEFEWRSMoo7F3VPIL4gbXuKlcJCiZareiLP/8vlYe0qr47Zmf6i Xi0JfoaM2wFrFPr4dh8MupGTRVLOeJxfKjlPwI8+hpwZsWw/3dvjC1hFaXlPrFGZu94s TUIsjl7cuCUeT4i0JKok0TVlCAePtL2QnjNsVo7IF8PNuFY9yO3KNiMFNwwPqhe9hCWx 740g== X-Gm-Message-State: AOAM532006LFAq1EqNwbOUjqxLNPO1mDlUZgzPZlbPnORNR2H1iC6q/i tUwWCcQROAGgSvtPt05/th2C+VzWo+CcfsNzYIk= X-Google-Smtp-Source: ABdhPJyLfrX19MHfTNU/khiG2sXYZMwst51eeFqBAva0HXWSfLYzGJ9VWz9PWCiPmlooYJdFOPL9bkYQ+xDJDzCe/Bo= X-Received: by 2002:a5d:4292:0:b0:210:1228:cefd with SMTP id k18-20020a5d4292000000b002101228cefdmr2331341wrq.519.1654155495935; Thu, 02 Jun 2022 00:38:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hugo Krawczyk Date: Thu, 2 Jun 2022 09:38:02 +0200 Message-ID: To: Neil Madden Cc: IRTF CFRG Content-Type: multipart/alternative; boundary="000000000000bd150205e0721608" Archived-At: Subject: Re: [CFRG] HKDF - difference in counter between original paper and RFC 5869 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 07:38:22 -0000 --000000000000bd150205e0721608 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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) =3D empty string (zero length) > T(1) =3D HMAC-Hash(PRK, T(0) | info | 0x01) > T(2) =3D HMAC-Hash(PRK, T(1) | info | 0x02) > T(3) =3D HMAC-Hash(PRK, T(2) | info | 0x03) > ... > > > Section 4.2 of the original paper [2] does indeed start the counter value > at 0: > > PRK =3D HMAC(XTS, SKM) > K(1) =3D HMAC(PRK, CTXinfo =E2=88=A5 0), > > K(i+1) =3D HMAC(PRK, K(i)=E2=88=A5CTXinfo=E2=88=A5i), 1=E2=89=A4i > I can=E2=80=99t find any rationale for why this change was made in the RF= C, so I > thought I=E2=80=99d check here in case anyone knows? Given that the count= er is only > a single byte, eliminating one of the 256 valid values seems unfortunate.= I > also can=E2=80=99t see any security or practical reason for doing so, but= perhaps > I=E2=80=99m 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 > --000000000000bd150205e0721608 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good question. I beli= eve (I checked some old email of mine with=C2=A0Pasi) this was done for com= patibility with the definition of HKDF in IKE (which is when I originally d= esigned HKDF,=C2=A0 though without a name and published analysis). I wasn&#= 39;t too happy about being limited by backwards compatibility but it was ju= dged at the time as one less hurdle for adoption.

Hugo

On Tu= e, 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 RF= C 5869 [1] starts the counter at 1 rather than 0:

   T(0) =3D empty=
 string (zero length)
   T(1) =3D HMAC-Hash(PRK, T(0) | info | 0x01)
   T(2) =3D HMAC-Hash(PRK, T(1) | info | 0x02)
   T(3) =3D HMAC-Hash(PRK, T(2) | info | 0x03)
   ...

Section 4.2 of the original pa= per [2] does indeed start the counter value at 0:

PRK=C2= =A0=3D=C2=A0HMAC(XTS,=C2=A0SKM)
K(1) =3D=C2=A0HMAC(PRK,=C2=A0CTXinfo=C2= =A0=E2=88=A5=C2=A00),

K(i+1) =3D=C2=A0HMAC(PRK, K(i)=E2=88=A5CTXinfo= =E2=88=A5i),=C2=A01=E2=89=A4i<t,

I can=E2=80=99= t find any rationale for why this change was made in the RFC, so I thought = I=E2=80=99d 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=E2=80=99t see any security or practical reason for doing so, but= perhaps I=E2=80=99m missing something?

(It happen= s to be a useful feature for me, but I suspect not deliberately so: a C pro= gram I am looking at uses HMAC and happens to include a null terminator byt= e 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).

Best wishes,<= /div>

Neil
__________________________________= _____________
CFRG mailing list
CFRG@= irtf.org
https://www.irtf.org/mailman/listinfo/cfrg<= br>
--000000000000bd150205e0721608--