Re: [TLS] padding bug

Bodo Moeller <> Tue, 24 September 2013 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71FCB11E8139 for <>; Tue, 24 Sep 2013 07:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.086
X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eCvxCw6tIT0j for <>; Tue, 24 Sep 2013 07:29:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B873121F96B1 for <>; Tue, 24 Sep 2013 07:28:44 -0700 (PDT)
Received: from ( []) by (node=mreu1) with ESMTP (Nemesis) id 0MMrlb-1VWTws2gxz-008GSv; Tue, 24 Sep 2013 16:28:42 +0200
Received: by with SMTP id g12so2232550oah.15 for <>; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kqaP3G5bmFuOPU/bWwydal6ob86LQMCXfYu6vgp7pOg=; b=jxMLINAlC0uMlKxoBz2todBLzTaue/BWiP0V6fK3hhkjnUkeklGSaWwkIYbZcAYJfb TX1ZXsGuGrFFHem9cb4K4IiKfyJ7NrvydCjgx1ucL5ZVMvF/LsUcDTnZpNmcJFsXTN57 EslVcjitlklsON9mKsaPYSLoXxy2eTXVskuildSVDjSPzIbzHrNLGHT/NdOTkV5y0k6g r8IG03PTQEsfYAryQ9tJx8qum8pTwpsxS6MykLTIs56klCFWux6XkFRNrKP6QZkgs6L/ ax0k6CtNi9XBiY4KiDof526C4ucPfhKgoA1HSoHbIMyA7WRXvDt115q1UuPWxLJDFvnJ /jLA==
MIME-Version: 1.0
X-Received: by with SMTP id q9mr511438oek.79.1380032920418; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
Received: by with HTTP; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 24 Sep 2013 16:28:40 +0200
Message-ID: <>
From: Bodo Moeller <>
To: Ben Laurie <>
Content-Type: multipart/alternative; boundary="089e013cc3a600026c04e721f496"
X-Provags-ID: V02:K0:nBPEKNv35XjfEWX3utt+/Hd6hPj0kC/iJtqrquspmZn VG9T7QXIADdFP5W9tJH96KefSVMdESGkGTmT+mGSSDFj8pnw/s PVpAu2oUBwlcPQGS2+zkSqC9V3JWy15ubFUkyY4nmlMJKG7qq8 Izpz/1bCkPRrxnwP6QFEXBEi9d2iev+n+0MCE6W7Nk/1BMqXLK NuQ5EcmXWr4xq1DennH3XGvle1fMsxON8Q387v8RPbwJQXVP/s /wnFou8fZOQDmEnyKHCzUX8G+poB1GnSPZjhvzjbBoAps2mUWy gEes9ob5hU8OSxj5mL6XtUeSJFscgy6axXF6yg/G4egnftm/gf 9f1kDP5d4saNXRxqO5CSFA3TE5IRBoTu16gLWZBSZ/X0VeMI3V j9Aej+DQZ7jvAhEWNJVwbbvGg5nM/q4dXc55jGPdDXrNzdBXDy pQs3Z
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 14:30:33 -0000

> > I take your question that you actually read RFC2104 and the
> > Preneel-van-Oorschot paper and you disagree with their points?

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

I think this reasoning is not quite right because that attack requires
*internal* collisions (and the internal state wouldn't be truncated).  Of
course, it's not an attack on HMAC.

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

Exactly. Given a particular l-bit MAC with an l-bit internal state,
truncating its outputs (such as to l/2 bits) isn't demonstrably an
improvement.  Rather, if we want an l-bit MAC, it makes sense to have an
internal state larger than l bits.

Nikos, you pointed to RFC 2104. The following is a literal quote from that
RFC: "The results in this area are not absolute as for the overall security
advantages of truncation."  In particular, encrypt-then-MAC with
untruncated MACs isn't a broken design.  (Assuming hypothetically there's a
key recovery attack on the MAC alone, the encryption step means that the
attacker can't pick MAC inputs after all.)