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

Michael StJohns <> Thu, 02 February 2017 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32965129696 for <>; Thu, 2 Feb 2017 08:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 4-i5SYIVi8Tl for <>; Thu, 2 Feb 2017 08:10:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9386B129490 for <>; Thu, 2 Feb 2017 08:10:57 -0800 (PST)
Received: by with SMTP id k15so38080066qtg.3 for <>; Thu, 02 Feb 2017 08:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=AoqA0CrDOXPwqVg+Qbg1fTkx3n0Frk+HUHjH9dMDoV4=; b=kESWMpOxfWuQDs+865WLhnHOCk04/RccWNuh3esn8XPur8ksZSJTipQTJ+2q3PfUMO ro04Ya3dMLITk9mhUAGMybsi5KW62DUCuUZhLDbYUx59WvnpGebqnJ8ugYroGxFx55YO FTiVZYQm/yC5w8p0KYUoAWonhdFGRv9+KCBt1j4m4Hwvz2NkxvnGwQaRmJYV+2DAhMON P7W8Hfu2bb/ZRCn/TdaxAsVKxXmA5ltN54XKm8N8Uf4y+NeU39kcscj3iff3l/9DO1kt Xa3G9UpYfgIZCa0ri82EIJyw+huRXkvCl0of3XnqsNCVlmZXeiT7ohNpb9ZWJUIqGg+q /g1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=AoqA0CrDOXPwqVg+Qbg1fTkx3n0Frk+HUHjH9dMDoV4=; b=elOTZZtHQ5ukSvfdJoVNdJAlSYxV3rrOcX1pbj5YpHqY83NJsAkRz+4NVIdfZqeJvR DNkBFmU8jM42+64dvgwcZWVKnNWXibLvIV+1yiQOV6zgjTFiU5dfrT9/MlqXT7ny4aE6 PrQJrIpRvNj/u/uBwkpAMTZKgGJAvLvWcx+9KZX4/Rz1+SWnY09mvOFAWmfPIAJ4uwPR s1Tdj3TFZeusvrW+/Z+i6ba/zCRK0U8Kv2rRNbA1jP6h/OmDUYfULo8M3jOHSQAlCPhc +xs8G9tXPDZpH0sRzUBh2Gjle27glNbQAvDe/inYVpWR1lfGGOi+NsqqnUeraXcff8zE UQCg==
X-Gm-Message-State: AIkVDXK/IMQKBG614KKDitFbhYkKrGQSInnSRALRj6NSJ9udR3i7trYXJh9xjv4vhtzYxQ==
X-Received: by with SMTP id l41mr9570789qtf.16.1486051855994; Thu, 02 Feb 2017 08:10:55 -0800 (PST)
Received: from ?IPv6:2601:152:4400:9b5f:c8f0:67e5:88b1:2975? ([2601:152:4400:9b5f:c8f0:67e5:88b1:2975]) by with ESMTPSA id q145sm21823318qke.37.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 08:10:55 -0800 (PST)
References: <>
From: Michael StJohns <>
Message-ID: <>
Date: Thu, 02 Feb 2017 11:10:59 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------BF1D8B98402EF4780EF84109"
Archived-At: <>
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:10:59 -0000


On 2/1/2017 9:24 PM, Stephen Farrell 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.

I think it's probably a bogus erratum.   Basically, there are a lot of 
ways to calculate check values for secret keys - hashing the key as 
suggested in this report - is not the one I would suggest for HMAC 
keys.  Instead, doing an HMAC over a known value - HMAC (K, 
'0000000000000000'b) to get a check value might be a better choice.

I think this report boils down to a "I came up with a way to use this 
mechanism in a way that may have security weaknesses".  If he'd said 
that IPSEC uses this and its bad, then I'd say the report was actionable 
- with respect to IPSEC.  As it stands, I'd reject the report.  
Alternately, I might say "Applications MUST not use keys longer than 8 
bytes, where the hash of the key (with the same hash as used in the 
HMAC) is also used as a public value (a key identifier or check value)".

And given that AFAICT RFC 2104 was really a feeder document for the 
NIST  FIPS 198-1 submission  (compare if you will the abstract of the 
RFC with the NIST document Introduction), I would suggest that any 
changes to HMAC be fed in to NIST rather than being accepted as updates 
to this informational document.


> Opinions welcome...
> Thanks,
> S.
> [1]
> _______________________________________________
> Cfrg mailing list