Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

Eric Rescorla <ekr@rtfm.com> Tue, 08 March 2011 18:21 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB103A68AF; Tue, 8 Mar 2011 10:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.913
X-Spam-Level:
X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKxLox9qk0PA; Tue, 8 Mar 2011 10:21:12 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4ED883A689A; Tue, 8 Mar 2011 10:21:12 -0800 (PST)
Received: by iwl42 with SMTP id 42so6415959iwl.31 for <multiple recipients>; Tue, 08 Mar 2011 10:22:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.45.137 with SMTP id uk9mr7118916icb.31.1299608547144; Tue, 08 Mar 2011 10:22:27 -0800 (PST)
Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 10:22:27 -0800 (PST)
In-Reply-To: <4D767242.10202@extendedsubset.com>
References: <AANLkTinHFPBWZdManf+awYiH1ExDhpRBjf=_HRi6EF8Z@mail.gmail.com> <201103081720.p28HKVFM002537@fs4113.wdf.sap.corp> <AANLkTimY8mSSj49-ETH96OTF4-ebzxTNTxm0Oo40XjS1@mail.gmail.com> <4D767242.10202@extendedsubset.com>
Date: Tue, 08 Mar 2011 10:22:27 -0800
Message-ID: <AANLkTik07Zte5ERfG_+GHd_ag9o3UguzCE6gEzjnSHKe@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Marsh Ray <marsh@extendedsubset.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 08 Mar 2011 18:21:14 -0000

On Tue, Mar 8, 2011 at 10:15 AM, Marsh Ray <marsh@extendedsubset.com> wrote:
> On 03/08/2011 11:33 AM, Eric Rescorla wrote:
>>
>> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex<mrex@sap.com>  wrote:

>>> Cutting down the SHA-384 output from 48 to 12 octets significantly
>>> impairs
>>> its ability to protect from collisions.  It's comparable to
>>> truncating the SHA-1 output from 20 to 5 octets.
>
> I think it's more comparable truncating SHA-1 down to 12 octets.

Yes, this matches my analysis.


>> I don't understand this analysis. Consider two ideal PRFs:
>>
>> * R-160 with a 160-bit output
>> * R-256 with a  256-bit output
>>
>> Now, consider the function R-256-Reduced, which takes the first 160
>> bits of R-256.
>> Are you arguing that R-256-Reduced is weaker than R-160? If so, why?
>
> I think he's arguing that anything cut down to 96 bits represents a lousy
> hash function allowing practical collisions on today's hardware.

Perhaps, but this isn't a digest but rather
a MAC, and so the attack model is different. Without knowing the key, you
basically have a 2^{-b} chance of producing an input which will pass the MAC
check, where b is the length of the MAC. Note that additional computational
power doesn't help much here because you still need to search the entire
key space, not the output space, in order to break the MAC.

However, the answer to *this* question is a distinct from whether a different
size hash function used as the basis for a MAC demands a different truncation.

-Ekr