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 5D6CB12996D for ; 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 ; 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 ; Fri, 3 Feb 2017 12:33:02 -0800 (PST) Received: by mail-yb0-x235.google.com 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; 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: References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> From: Hugo Krawczyk Date: Fri, 3 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: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:33:05 -0000 --94eb2c1b0ba02dae1e0547a630f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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) 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 has= h > 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 sa= me > 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 th= e > key and its length encoding did not get longer than the hash function inp= ut > 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 < > 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... > > =E2=80=8BThese cases of related key setting=E2=80=8Bs are well known and= can indeed be > seen as a weakness of HMAC. They are part of the engineering trade-offs y= ou > have to do for accommodating a design to the real world (and requirements > from often chaotic IETF discussions). There were things we would have lik= ed > 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 theoretic= al > 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 n= ot > 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 mo= re > significant than the potential problems of such related key issues. > > Hugo > > > > > > > --94eb2c1b0ba02dae1e0547a630f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry Quin ;-)

I knew I had to go look at the spelling but was rushing too much... Le= t'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 consideratio= ns invalidate HMAC as a PRF. Your statement "HMAC is not a PRF" i= s 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 har= d to argue with 20 years of widespread and robust use. If this was a real i= ssue, it would have come in some significant practical situations but it ha= sn't. I see no justification to change the standard after (exactly) 20 = years.=C2=A0

Hugo

On = Fri, Feb 3, 2017 at 2:47 PM, Dang, Quynh (Fed) <quynh.dang@nist.gov&= gt; 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 ha= sh function output). But in the RFC specification of the HMAC, the key is &= quot;any" length.


I am sure you saw that b bits of =C2=A0(key||00000....) created the situ= ation that many keys produced the same output from the function HMAC for th= e same message input when the=C2=A0key's length was not a fixed value. = If you wanted a variable key length, you would have had at least 2 options: (1)=C2=A0adding encoding for key length and p= ut some restriction on key length so that the key and its length encoding d= id not get longer than the hash function input block (avoiding one hash fun= ction call to improve performance) or (2) always hashing the key to produce the exact length L for the key.=C2= =A0


Quynh. =C2=A0

From:= Cfrg <cfrg-b= ounces@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...
=C2=A0
=E2=80=8BThese cases of =C2=A0related key setting=E2=80=8Bs are well known = and can indeed be seen as a weakness of HMAC. They are part of the engineer= ing 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 t= he longer-than-block keys or having different keys for the inner and outer = hash applications, but that would have made the design problematic in diffe= rent ways. The particular issue of not disallowing keys longer than a block came at least from an IKE requ= irement. For example, people wanted to use unlimited passphrases, and betwe= en having people truncate long keys or hash them first, the latter seemed t= he 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 weak= ness (I have myself shown such cases) but either these were theoretical set= tings or some forms of bad practice (e.g. making the hash of a secret key p= ublic). The paper cited earlier by Dan Brown also notes that this property makes HMAC with long keys non-i= ndifferentiable from a random oracle. Again, not the nicest property but ha= rdly 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 engineeri= ng considerations (not breaking existing implementations) are more signific= ant than the potential problems of such related key issues.=C2=A0

Hugo







--94eb2c1b0ba02dae1e0547a630f0--