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

Martin Rex <mrex@sap.com> Tue, 08 March 2011 18:29 UTC

Return-Path: <mrex@sap.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 9F0C63A6921; Tue, 8 Mar 2011 10:29:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.222
X-Spam-Level:
X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 HE88CKqVPHIY; Tue, 8 Mar 2011 10:29:27 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C51F93A693F; Tue, 8 Mar 2011 10:29:26 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p28IUdL0006668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 19:30:39 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201103081830.p28IUdtN006451@fs4113.wdf.sap.corp>
To: ekr@rtfm.com
Date: Tue, 08 Mar 2011 19:30:39 +0100
In-Reply-To: <AANLkTimW9kC2gsrxnuW47pGjjoaK_mB5QaMbLKS+0aAo@mail.gmail.com> from "Eric Rescorla" at Mar 8, 11 10:11:38 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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
Reply-To: mrex@sap.com
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:29:54 -0000

Eric Rescorla wrote:
> 
> On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex <mrex@sap.com> wrote:
> > Eric Rescorla wrote:
> >>
> >> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex <mrex@sap.com> wrote:
> >> > Eric Rescorla wrote:
> >> >>
> >> >> I don't understand this reasoning. Why does the output size of the
> >> >> pre-truncated PRF
> >> >> influence the desirable length of the verify_data (provided that the
> >> >> output size is > than
> >> >> the length of the verify_data of course).
> >> >
> >> > One of the purposes of a cryptographic hash function is to protect
> >> > from collisions (both random and fabricated collisions).
> >> >
> >> > 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 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?
> >
> > What we're having are the two cases:
> >
> >  1)  R-160 truncated to 96 bits
> >  2)  R-256 truncated to 96 bits
> >  3)  R-160 with full 160-bits
> >
> >
> > If your primary focus was collision avoidance, then
> > 3) is stronger than 1) and 2) by a huge margin.
> 
> Yes, I totally agree.
> 
> 
> > There may be reasons why you don't want (3), like an attackers ability
> > to verify when he guesses keys correctly that are input to the PRF.
> >
> > When 20/12 is a good truncation ratio for a 160-bit PRF,
> > then 48/12 looks like a poor truncation ratio for a 384-bit PRF
> > (and SHA-384 is already a truncated SHA-512 anyway).
> > Applying the 20/12 tradeoff to R-256 results in approximately (32/20)
> > and to R-384 results in approximately (48/28) -- with (48/32) probably
> > sufficiently close.
> 
> I don't understand this analysis at all. Again, are you arguing that
> (1) and (2) have different security properties?

In case they were both "ideal" - no.

But in that case, asking anyone for the effort to replace
1) with 2) would be a complete waste of resources.


If we move in a new, stronger crypto-algorithm, then we should not
unreasonably spoil its properties.

Truncating a SHA-384 based PRF to 12 octets is like using
an sha384WithRsaEncryption signature with a 1024 bit RSA key,
it is an imbalanced pairing of algorithms&keys.


-Martin