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

Xander Sherry <> Thu, 02 February 2017 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3A89129686 for <>; Thu, 2 Feb 2017 07:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 tEBvt6buCVIp for <>; Thu, 2 Feb 2017 07:52:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB4EF12968D for <>; Thu, 2 Feb 2017 07:52:49 -0800 (PST)
Received: by with SMTP id f9so14821795otd.1 for <>; Thu, 02 Feb 2017 07:52:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BHgHzyoWuRrhb1R2BNVxgY4YRg1lMd4HJwjql0tFsqs=; b=Xlm1enJX6WPIuANOHnQb8KhMS8ZpWa2hLmz3n0v7elbI9TIMPfMm2al/N8QoL6ILvY D2bQFCTQMLgWoCTCTeFx16F6zXRGQ/HWR+AqcAt16jcLMv1iOBvJyhERq4Opod2jkTO/ oI+UQosahXS86uJZl2bDMA7UeKyw9pNBQXcfPKS7Bu6GaNdLCB6U6GcnSrIDb622AWXE Rs4cNyuw/4Ljnx3oBM23pA7/3uFkV1a3Ofr16OeIHoV65gjfMNHphI4voOUmfz40rEZ6 FALMz5Iu0BCsSpB1/CoKVvSkK4XBTguARJR3BOp63RpbSe15igP6zZt43rFWxXjXJhlb b7yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BHgHzyoWuRrhb1R2BNVxgY4YRg1lMd4HJwjql0tFsqs=; b=DWYhJxO0lZxoSbRB9czTpkbTmv1HvuhCuHX3SnlLGC6Oa4bq3QRuxh+V20kj2wHYC/ kbAcxd0PuYP4aM/WXl8EFJlkn0o6ytL2ekykGbbkdk7nFLuoZRKNCBtmJBrC+nHKHxLW zWJiijEdHtgfrl4xRzKB6xqalkVT0h1aMuY4UYEolwmVj68IsqhDUjI01pKJ2DiSO/KY 0+6m3wvumg86fCuL6500Wdi+lmw6qes66zE7v3jlfAX9Azb8iCtB8Z3Vdx1xCDe49pUH x+EsWWMbdG/q3774TbEI1kfPRqZ7Q/Pdn2ciC9i7N8RB8in4fRHJsGzkX675NhDWIhbx of+Q==
X-Gm-Message-State: AIkVDXLHj7dmvM9Yv9I+DcecKW5NI8nCAt/24pFERmvsMtXPMpRaaKa9C2Fip7lJsCJ31ed0bAClC81WoPybxQ==
X-Received: by with SMTP id r13mr3984394otb.203.1486050768879; Thu, 02 Feb 2017 07:52:48 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 2 Feb 2017 07:52:48 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Xander Sherry <>
Date: Thu, 02 Feb 2017 10:52:48 -0500
Message-ID: <>
To: "Paterson, Kenny" <>
Content-Type: multipart/alternative; boundary="001a113d15dc329e7105478e28e3"
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 15:52:53 -0000

Speaking not as an HMAC expert but as an application security guy, while I
agree that the ares where the design of HMAC could be improved, the
vulnerability described in the proposed errata is, in my opinion, less a
security issue with HMAC, and more a security issue with a badly designed
system.  I can immediately think of several ways to mitigate the threat,
not the least of which is simply not to build a system that stores
plaintext hashes of bare keys.

As we all well know, virtually any cryptographic design can (and will!) be
implemented badly in ways that introduce vulnerability, when the
implementer doesn't understand the system he or she is implementing, which
is exactly what the scenario in question seems to be.   Generally speaking,
I think HMAC is easier than most to implement reasonably securely, and even
where it is not, this particular case is not where it is likeliest to fail.
  Short colliding keys as Kenny mentioned are certainly a bigger issue, and
weak keys and non-constant-time comparison are other issues I see regularly
in real systems.

On a tangent, purely as personal opinion, errata is a great tool for fixing
mistakes and adding clarification.  It's a lousy way to propose a
fundamental breaking change to an RFC that's been published for 19 years
and is already baked into who-knows-how-many systems in its current

Best regards,

-Xander Sherry

On Thu, Feb 2, 2017 at 9:07 AM, Paterson, Kenny <>

> Dear CFRG,
> It'd be great if some HMAC experts could take a look at this proposed
> erratum and give a view on it.
> I looked quickly myself. It's an undesirable property, but I don't think
> it's disastrous (yes, I could invent scenarios where one could come
> unstuck because of it). It reminds me somewhat of the well-known, and
> again somewhat unfortunate, fact that HMAC keys of different lengths can
> end up being padded to form colliding keys.
> Cheers,
> Kenny
> On 02/02/2017 02:24, "Cfrg on behalf of Stephen Farrell"
> < on behalf of> wrote:
> >
> >Hiya,
> >
> >There's an erratum posted for hmac [1] where I'd be
> >interested in what folks here think.
> >
> >I'm unsure if this is a real problem, esp given that
> >there are I guess a lot of implementations.
> >
> >And even if it were a real problem, I'm not sure we'd
> >want that fix.
> >
> >Opinions welcome...
> >
> >Thanks,
> >S.
> >
> >[1]
> >
> eid=4809&rec_status=
> >15&area_acronym=&errata_type=&wg_acronym=&submitter_name=&
> stream_name=&sub
> >mit_date=&presentation=records
> >
> _______________________________________________
> Cfrg mailing list