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

Hugo Krawczyk <> Fri, 03 February 2017 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D6CB12996D for <>; Fri, 3 Feb 2017 12:33:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IOYta66PtUpv for <>; Fri, 3 Feb 2017 12:33:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1C5A129521 for <>; Fri, 3 Feb 2017 12:33:02 -0800 (PST)
Received: by with SMTP id o65so9554192ybo.2 for <>; Fri, 03 Feb 2017 12:33:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UHxNliFWwYgFInpCZxcrGdnXdOJK/HhGCr7xu2y02UI=; b=vWXfvF9spP2hC0jwqexhjeOc9Z2xJ+5U7Uj7Tkpl3N0nPGI20iQMMCNd3dnrLMqnGr GJBzGP9H1SOixpo4kbhr5nrI1qqAIRlqNx9KEUgaAHT/sKY1jIYYsdjQxDBmszMvMOBi HJSTeoM978m+BrILJen0q7eEHs47WpFgk/oD8fnM27MsNqNJls2rI3sJXju/83ZGAcCc YhbytWIhrDyBPlxoVg1DILbKa53BWHHprZ9DUUpoBwvLIRr6BZja/omyPNKlbvahEZZr Z1meM6javBcZz9mi7y596zxmK7NVd1AtmfPUqBx+R+isPBhBFJLPzrvm0tSdbj5VRf8I uG6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UHxNliFWwYgFInpCZxcrGdnXdOJK/HhGCr7xu2y02UI=; b=rUi96aqkIHIiE+qgA7v2yFD0Qf6dI3VnllrlDD9ZPtRPoOe/5hoT8Qj2GovNUjIC8M QHs1yMuUWzf3A+WZMJt+/baHFlGX3Yam6D0iLDJ2NxS7ovccLJnFBsCgbeNihWEhBMZT R5r2F24jnY4xatyzvaLhF6XUGAzGJ/I0qzMAM5j0qS3uwgeBJ+oRN4hAOlnhMGSLCA0y pjOmyrip+MMxA+aCcoDEScwLWWX6g/HcbvEtIYeB6aB6LurCQGZGVRBQvjiJSfUghpTF cAM+8qCaWV41yjISQ/DUcWDhpuseREe8BHmAe4IyJfphnrnAErufuthRnF4QNEFkRGFA gyHQ==
X-Gm-Message-State: AIkVDXJPlJTgH+IuzNezXhSDjZNq4tv9f647cQ2qQqqojs/f3DGbSwLxt8OcokTbhNBtPj/Jp7KF8jUPYDUCNA==
X-Received: by with SMTP id t19mr7441754ybt.177.1486153981990; Fri, 03 Feb 2017 12:33:01 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Feb 2017 12:32:31 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Hugo Krawczyk <>
Date: Fri, 03 Feb 2017 15:32:31 -0500
X-Google-Sender-Auth: p12PHl7nbXUu9VBzjD3dJhdfSx8
Message-ID: <>
To: "Dang, Quynh (Fed)" <>
Content-Type: multipart/alternative; boundary="94eb2c1b0ba02dae1e0547a630f0"
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 20:33:05 -0000

Sorry Quin ;-)

I knew I had to go look at the spelling but was rushing too much... Let's
see how you spell my last name from memory :-)

To the technical point: regardless of what could have been the best
resolution to variable length keys, neither of these considerations
invalidate HMAC as a PRF. Your statement "HMAC is not a PRF" is wrong (and
can add unjustified and unwanted confusion).

As I said, practice constraints us in different ways and produce
sub-optimal results. But in the case of HMAC, really, it is hard to argue
with 20 years of widespread and robust use. If this was a real issue, it
would have come in some significant practical situations but it hasn't. I
see no justification to change the standard after (exactly) 20 years.


On Fri, Feb 3, 2017 at 2:47 PM, Dang, Quynh (Fed) <>

> 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.
> Quynh.
> ------------------------------
> *From:* Cfrg <> on behalf of Hugo Krawczyk <
> *Sent:* Thursday, February 2, 2017 11:22:25 AM
> *Cc:*
> *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.
> Hugo