IETF Logo Mail Archive

Re: [TLS] padding bug

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Wed, 11 September 2013 18:24 UTC

Return-Path: <prvs=2966a68272=uri@ll.mit.edu>
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 4A60511E80A2 for <tls@ietfa.amsl.com>; Wed, 11 Sep 2013 11:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 9VYdpmgTmDiO for <tls@ietfa.amsl.com>; Wed, 11 Sep 2013 11:24:20 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id B39DB11E820F for <tls@ietf.org>; Wed, 11 Sep 2013 11:24:18 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8BICmd0028888; Wed, 11 Sep 2013 14:24:08 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "benl@google.com" <benl@google.com>, "tls@ietf.org" <tls@ietf.org>, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Wed, 11 Sep 2013 14:23:27 -0400
Thread-Topic: [TLS] padding bug
Thread-Index: Ac6vHAPhQ6+K8df9RgeSa3vF12wT5g==
Message-ID: <CE5627E4.110C3%uri@ll.mit.edu>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735566CD97@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.7.130812
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3461754207_5404671"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-11_06:2013-09-11, 2013-09-11, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309110105
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: Wed, 11 Sep 2013 18:24:25 -0000

On 9/11/13 2:02 , "Peter Gutmann" <pgut001@cs.auckland.ac.nz> wrote:


>Nikos Mavrogiannopoulos <nmav@gnutls.org>
>
>>Do you have any reference for that? RFC2104 and the paper it references
>>claim otherwise.
>
>Oh man, that'd require ploughing through 15-year-old email discussions...
>to see it in effect, look at section 2 of RFC 2402.

I see no presented evidence of having a clue.

There's nothing in RFC 2402 that would support your (unfounded)
speculation. On the other hand, section 6 of RFC 2402 refers to the two
mandatory-to-implement RFC 2403 (HMAC-MD5-96) and 2404 (HMAC-SHA-1-96).

RFC 2404 section 5 (Security Considerations, unsurprisingly), 4th
paragraph refers to RFC 2104 and explicitly mentions ADDITIONAL SECURITY
PROVIDED BY THE TRUNCATION OF THE RESULTING HASH.

Finally, RFC 2104 (HMAC) section 5 (Truncated output) describes the
cryptographic consequences of truncating the hash (less information on
hash result available to attacker vs. fewer bits to predict), with
reference to Preneel and Van Oorschot paper from Crypto'95 "Building fast
MACs from hash
           Functions".

Enough?

v2.23.0 | Report a Bug | By Email