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

Hugo Krawczyk <> Thu, 02 February 2017 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63F59129458 for <>; Thu, 2 Feb 2017 08:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.876
X-Spam-Status: No, score=-0.876 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M6Tvi4t8Qedm for <>; Thu, 2 Feb 2017 08:22:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F75C12943F for <>; Thu, 2 Feb 2017 08:22:56 -0800 (PST)
Received: by with SMTP id j82so862810ybg.2 for <>; Thu, 02 Feb 2017 08:22:56 -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:cc; bh=8oZ4MFmYkDd4CfMBO/X16BvlPn7kPyfEZUH7EmhmuUE=; b=AVed+ilnXTBZ+mu4p1GAOK4CnOc3Rz4Uqks5LP7+/+2nc8sekkCk10Q0IeBiTozFIB W3fC5EOYDL0MR86mX2qksLCsGoxB9xpgddo94ZjKNdlzEyaLBQuBpLLNnX7wyGPqaUkr o4A/jr6C8GNybErEtXo5ujEXsW8sUk2Jj6pPTQFmIOC4hB1orTcB2XFBgE66GMJ8V5uD bjSIb8xUD4s7z0OZw/JtdkCp9eRgILKJG4sMbTk9HidJAtghQSS/axjI547k06+ETRhH 3id17aoA/hTZGg24+haEm843oTzaN5eAkFY8bP0aU83ctDnd0d78s4CMNeHgT9Y9fydq JE7A==
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:cc; bh=8oZ4MFmYkDd4CfMBO/X16BvlPn7kPyfEZUH7EmhmuUE=; b=QhJJLbQ1H/IEy102OaNH87/wa+T+oAiJQKla/M6jYNme3mg0+B8EJ3PdsVFY9QJwJN kPtuZxmTMIJ7579Kv9drsLPTuPWI1yeqCYPqnj6ImmF6gJoWNJGb06nWNnWrkBnQFuew M1JDx6PIeuOVwN5Bm8QQEP3K/EZcONr0hYreVbW52f2z9WaEWuPyhbReQG4phEnxOtS+ zNNhBaA1yNXwITav2MWkYeCwieBMfZ/PhzUXAnHJtHsCjnWajz883IG64q3WRitiAbiV DNjNkqOC+2GQAJHeSBjn0FehEv4GSDEUjh0VoHU2gZt6XR+p16QiINRbYqRyltVgWvue azWw==
X-Gm-Message-State: AIkVDXIcjHb7wl+h48S2CZs+nAgFKJlXFSvUb6pI31VC+mAeR3zF2NzQtVSgGJns7J6qVI79Mmb/C206JtcyiA==
X-Received: by with SMTP id k190mt3262295yba.147.1486052575751; Thu, 02 Feb 2017 08:22:55 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 2 Feb 2017 08:22:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Hugo Krawczyk <>
Date: Thu, 02 Feb 2017 11:22:25 -0500
X-Google-Sender-Auth: d2j_dIGK1rKiCJrhLXlPxC061vA
Message-ID: <>
Content-Type: multipart/alternative; boundary="001a114bd0c6e59f0305478e9310"
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: Thu, 02 Feb 2017 16:22:58 -0000

​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.