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

Hugo Krawczyk <hugo@ee.technion.ac.il> Fri, 03 February 2017 20:33 UTC

Return-Path: <hugokraw@gmail.com>
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 5D6CB12996D for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2017 12:33:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOYta66PtUpv for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2017 12:33:03 -0800 (PST)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C5A129521 for <Cfrg@irtf.org>; Fri, 3 Feb 2017 12:33:02 -0800 (PST)
Received: by mail-yb0-x235.google.com with SMTP id o65so9554192ybo.2 for <Cfrg@irtf.org>; Fri, 03 Feb 2017 12:33:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.37.45.19 with SMTP id t19mr7441754ybt.177.1486153981990; Fri, 03 Feb 2017 12:33:01 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.37.44.82 with HTTP; Fri, 3 Feb 2017 12:32:31 -0800 (PST)
In-Reply-To: <CY4PR09MB1464ED9008BCF397A0228C00F34F0@CY4PR09MB1464.namprd09.prod.outlook.com>
References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> <D4B8ED5B.83EFC%kenny.paterson@rhul.ac.uk> <CAAQpVOhTHLHFKgWYFnhpW7fHju1i5N83yzaR3x4+Ea1+M5hzbQ@mail.gmail.com> <CADi0yUNCXneU4CbWT=KZ6CckR0Dv93XKoAUwRVsskE+MRijOZw@mail.gmail.com> <CY4PR09MB1464ED9008BCF397A0228C00F34F0@CY4PR09MB1464.namprd09.prod.outlook.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Fri, 3 Feb 2017 15:32:31 -0500
X-Google-Sender-Auth: p12PHl7nbXUu9VBzjD3dJhdfSx8
Message-ID: <CADi0yUO4hp_-4nxVCXy_8e_w7s0xyh+Jq0Bgw5Rmr0B0jt7iww@mail.gmail.com>
To: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
Content-Type: multipart/alternative; boundary=94eb2c1b0ba02dae1e0547a630f0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/m8rKTuyGYoduFOznrjgIzYXx1LM>
Cc: "cfrg@irtf.org" <Cfrg@irtf.org>
Subject: Re: [Cfrg] erratum for hmac what do we think...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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.

Hugo


On Fri, Feb 3, 2017 at 2:47 PM, Dang, Quynh (Fed) <quynh.dang@nist.gov>
wrote:

> 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 <cfrg-bounces@irtf.org> on behalf of Hugo Krawczyk <
> hugo@ee.technion.ac.il>
> *Sent:* Thursday, February 2, 2017 11:22:25 AM
> *Cc:* cfrg@irtf.org
> *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
>
>
>
>
>
>
>