Re: [TLS] padding bug

Bodo Moeller <bmoeller@acm.org> Tue, 24 September 2013 14:29 UTC

Return-Path: <SRS0=2RbL=TE=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FCB11E8139 for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 07:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.086
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCvxCw6tIT0j for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 07:29:01 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id B873121F96B1 for <tls@ietf.org>; Tue, 24 Sep 2013 07:28:44 -0700 (PDT)
Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MMrlb-1VWTws2gxz-008GSv; Tue, 24 Sep 2013 16:28:42 +0200
Received: by mail-oa0-f42.google.com with SMTP id g12so2232550oah.15 for <tls@ietf.org>; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.60.39.169 with SMTP id q9mr511438oek.79.1380032920418; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
In-Reply-To: <CABrd9SQQ0Ormyx=wjnXO+Z-Zo52x_tYV7R4XuLMgbyHf2X7H=w@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org> <CABrd9SRHheYhNjcbKosaEASfJ6EvZtN93HaLG=Cvzn_1ohKFgw@mail.gmail.com> <524176EA.3090401@gnutls.org> <CABrd9SQQ0Ormyx=wjnXO+Z-Zo52x_tYV7R4XuLMgbyHf2X7H=w@mail.gmail.com>
Date: Tue, 24 Sep 2013 16:28:40 +0200
Message-ID: <CADMpkcKhCsunTd2wAecXWjXxrHGG-18v7aaZ40fG31qZw1zkcQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Ben Laurie <benl@google.com>
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: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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.)

Bodo