Re: [Cfrg] erratum for hmac what do we think...

"Dang, Quynh (Fed)" <> Fri, 03 February 2017 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83EC012952B for <>; Fri, 3 Feb 2017 11:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 71Y-p0gDZ_eb for <>; Fri, 3 Feb 2017 11:47:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EB3212950C for <>; Fri, 3 Feb 2017 11:47:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XFjIAmUcO7ovIU4SrMtHq7Fty5EuJ2Lt2t6Qs1d2wQc=; b=lCFRWEq8vlcLWRuNZ76+KuIunoNNcpb6sLX/1ObHoj2dfW02OQeME1tPkNlxy2okxCnuADdZT8XSbDluNh7ZLNturA+sWwTEkbgiX3LG6uiNUEwCFoyGOYGmOcYftYGvxmFu014NZHX83Zj4vh4g88ufQYU/Ph1dzQNhu5CGbo0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 3 Feb 2017 19:47:36 +0000
Received: from ([]) by ([]) with mapi id 15.01.0888.020; Fri, 3 Feb 2017 19:47:36 +0000
From: "Dang, Quynh (Fed)" <>
To: Hugo Krawczyk <>
Thread-Topic: [Cfrg] erratum for hmac what do we think...
Date: Fri, 03 Feb 2017 19:47:35 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 54035ea6-6bbe-4822-bb93-08d44c6d80af
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463;
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:6iAc78m866ngcXcBTd1XRaVPkyKmm0G1PVbsaHAMC6DV8v7na86Rvpx1Vfdn37+jJdzQltfLXstCRJ7u4Wi9UhlCCTrmDozYd3+9/mPSB9Bjg1jgXM3XLJOKdmVnq0tL9BebVkYxf7C4GmbeuxvHh6nYvQD73NwTKUVsa9vYRNCQ+weickQ7ma6G1zeqEz59KzOiLAmb8IAr2Qvu7A5Gum+Tzh+Jhyk98jqN3mCdDl5daI3GDLtM6RT78fSRobmq3mQySxc9ueg9YUgIQ/WpmWoH/rZ5y4357WVTZ0J3BFip6iPU8zHS7J0nug+w4KV2eLr3qphfSXc6+w+iXBsxo3gzplxpakBHauEMjzVfyQ/t80SNKAq4Nbcceed/XrlBCujMWr6uyPDy0OLphGfr+bM0oNFNvLtLitPRVNGUrKHFEj9oPOlids0gvlXH9ZsDbRwPKBaek7lUZv/mtOrAtc+wk3iRtkEgqmSMeVEOQnjCC8jvfKhdbi9Kc/op95xbkv6C7Vc1KvNAsA3gG5bERA==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(278428928389397);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463;
x-forefront-prvs: 02070414A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39840400002)(39410400002)(39450400003)(52314003)(377454003)(189002)(199003)(6116002)(102836003)(4326007)(3846002)(3660700001)(25786008)(77096006)(6436002)(189998001)(54896002)(9686003)(3280700002)(93886004)(99286003)(53936002)(55016002)(2900100001)(6506006)(66066001)(2906002)(2950100002)(68736007)(38730400001)(33656002)(345774005)(229853002)(8936002)(5660300001)(19627405001)(76176999)(122556002)(7696004)(110136003)(92566002)(101416001)(54356999)(8676002)(50986999)(6246003)(7736002)(97736004)(74316002)(86362001)(106356001)(106116001)(6916009)(81156014)(81166006)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB1464ED9008BCF397A0228C00F34F0CY4PR09MB1464namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 19:47:35.8567 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] erratum for hmac what do we think...
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Feb 2017 19:47:39 -0000

Hi Hugo,

Thank you for calling me a nice name "Quin"!

In the HMAC paper, the key length is the IV length (the length of the hash function output). But in the RFC specification of the HMAC, the key is "any" length.

I am sure you saw that b bits of  (key||00000....) created the situation that many keys produced the same output from the function HMAC for the same message input when the key's length was not a fixed value. If you wanted a variable key length, you would have had at least 2 options: (1) adding encoding for key length and put some restriction on key length so that the key and its length encoding did not get longer than the hash function input block (avoiding one hash function call to improve performance) or (2) always hashing the key to produce the exact length L for the key.


From: Cfrg <> on behalf of Hugo Krawczyk <>
Sent: Thursday, February 2, 2017 11:22:25 AM
Subject: Re: [Cfrg] erratum for hmac what do we think...

​These cases of  related key setting​s are well known and can indeed be seen as a weakness of HMAC. They are part of the engineering trade-offs you have to do for accommodating a design to the real world (and requirements from often chaotic IETF discussions). There were things we would have liked to do differently such as avoiding the longer-than-block keys or having different keys for the inner and outer hash applications, but that would have made the design problematic in different ways. The particular issue of not disallowing keys longer than a block came at least from an IKE requirement. For example, people wanted to use unlimited passphrases, and between having people truncate long keys or hash them first, the latter seemed the more robust solution. (BTW, the right way to deal with these issues using HMAC is to use HKDF.)

Anyway, over the years I heard some rare instances where this led to a weakness (I have myself shown such cases) but either these were theoretical settings or some forms of bad practice (e.g. making the hash of a secret key public). The paper cited earlier by Dan Brown also notes that this property makes HMAC with long keys non-indifferentiable from a random oracle. Again, not the nicest property but hardly something to worry much about in practice. Also, contrary to what Quin said, this property does not contradict HMAC being a PRF (PRFs can have related key weaknesses).

After 20 years of widespread use, it seems to me that (again) the engineering considerations (not breaking existing implementations) are more significant than the potential problems of such related key issues.