Re: [TLS] padding bug

Ben Laurie <> Tue, 24 September 2013 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5880F21F963F for <>; Tue, 24 Sep 2013 04:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7PG2voQUAXfl for <>; Tue, 24 Sep 2013 04:40:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22d]) by (Postfix) with ESMTP id 782B921F9642 for <>; Tue, 24 Sep 2013 04:40:40 -0700 (PDT)
Received: by with SMTP id ar20so8797813iec.18 for <>; Tue, 24 Sep 2013 04:40:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vXLrtIzy3ku9fbMIFsuL+iCBRwk6BmU0pmcl/72TQbc=; b=owj1JES9YABSANFcvDaGfVHpa0zI/6cixp/d5DoTFwytPTbyIL/Mp5VfYqyG3ShJOk Mm4UfghPnt7zxxTxA1od+e5+VmZ08han8Q3ZLeCeltG07iP+nMCf6GwrIC7AI/I4y24b QhvPMKK4E1l4uOHtReq5LA41qTsQwg536B8+OjlgrRVjmCQ+1b8takaj8pn7NdMiKz+v EbtryMTrc3beC0v28eAelZr9j22lL5lx/KY2aiKwyi7Bw/a60ZlMnMuNDcz7AZGctBRx QZVkAXtHcNiqfTSR4NjABUoWmh2/2coOizN/5hTAHXDE+8/mP2IOskZBFrLREcgV6PAA jlSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vXLrtIzy3ku9fbMIFsuL+iCBRwk6BmU0pmcl/72TQbc=; b=EYIlxzKtFuDJ4zS/XYO2h4OHi+4bKE+IxbRQYoyB4dr9pA+PE0UpMBRbdxz6ybjLpD 3YnZkrqANjHtzgI390LSViwJBFt9lXLeJb9osVlMkL/PaKQOPtl1BZr55HRf2b6AgjB7 UZ991yOTLah3FhO1BFppXAtRB/JusOQ6NTqDHUY+YiU8ORKOfEamksq2QjAOsoSnDt02 KB1oSx3ous2MekkRHBWMDkkWc7sD3TAZkJsbJfEn3G2JFbrOpuUSYWAyTPU6dx1ILx0Z uhQUjCyPbWZJ7I21xRTy/2PP5QkElxmmedASeZB20acCbgG+QRyYGBunIrFuAm7Ox7dg 1AAg==
X-Gm-Message-State: ALoCoQkW8A0zHlmik2sfZ61xikF8m3yv6fRNY9wq1SNAcRUAhvdyQatTj5O0vwZ4vOpGEh7TkjDt4/tHXvdWNOdHXR/oKUiEO0gciyel2viajmyQ/7VDsXrKzoIFiB1wF44TPX85xhwJfixDn1vMdm517dmOGKOHv3EeyliPf2GeUgkQaaxW2gf6+etto4wchertl/CHTz18
MIME-Version: 1.0
X-Received: by with SMTP id gn10mr2452701icb.17.1380022839554; Tue, 24 Sep 2013 04:40:39 -0700 (PDT)
Received: by with HTTP; Tue, 24 Sep 2013 04:40:39 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 24 Sep 2013 12:40:39 +0100
Message-ID: <>
From: Ben Laurie <>
To: Nikos Mavrogiannopoulos <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>
Subject: Re: [TLS] padding bug
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2013 11:40:45 -0000

On 24 September 2013 12:26, Nikos Mavrogiannopoulos <> wrote:
> On 09/24/2013 12:24 PM, Ben Laurie wrote:
>>>> Just a small amount of Schadenfreude here when I point out that
>>>> as I was reading through the long list of GnuTLS security
>>>> advisories at it seems that a
>>>> number of them would have been avoided through the use of the EtM
>>>> that Nikos has been so strongly opposed to :-).
>>> I don't understand what does this prove. I was one of the first to
>>>  ask for a solution to the issue. Pointing an issue in your draft
>>> doesn't mean I'm against solving the problem.
>> The issue you claim is that it does not defend against key recovery
>> attacks. I am not aware of any key recovery attacks against HMAC,
>> and MAC truncation was not proposed as a countermeasure for a key
>> recovery attack against any MAC.
> Hello Ben,
>  I believe it would be better to consult the opinion of an expert on
> hash functions and MAC designs. The fact that you (or me for that
> matter) don't know something doesn't mean much.

I have consulted experts. This is why I am puzzled by the objection.

>> Can you provide a reference for your claim?
> I believe we make circles. I previously referenced IPSec (RFC2104) at:
> The same RFC references the Preneel-van-Oorschot paper.
> I take your question that you actually read RFC2104 and the
> Preneel-van-Oorschot paper and you disagree with their points?

Actually, I did, and I don't disagree with their points, but I
disagree with _your_ points.

a) The paper describes a collision attack, not a key recovery attack.

b) Step one of the attack is "find a collision". Since that is
impractical, even for (untruncated) HMAC-MD5, hash truncation provides
no useful defence against the attack.

c) In any case, the whole point of the truncation defence is to make
it harder to go from _observing_ a colliding MAC to the ability to
construct more collisions. But it mostly does this by making it easier
to observe MAC collisions.

d) If you _really_ want to defend against this attack, the right
answer is to design hash functions with bigger internal state.

> PS. I attach the comment of Bart Preneel on the topic (a cryptographer
> with significant expertise on hash functions).

In which he says he was right for the wrong reasons. So, you need to
reference the right papers (i.e. the ones that describe key recovery
attacks) so we can evaluate the severity of these attacks. I am not
aware of any even vaguely practical attacks against even HMAC-MD5, let
alone any HMAC we're actually contemplating.

Please present your evidence.

(Incidentally, he also agrees that the right answer is to have larger
internal state, not to truncate. SHA-3 gives us this, right?).