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

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Tue, 08 March 2011 21:14 UTC

Return-Path: <prvs=2048c768d4=uri@ll.mit.edu>
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 028723A63C9 for <tls@core3.amsl.com>; Tue, 8 Mar 2011 13:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level:
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 SRT-g9+b-j+7 for <tls@core3.amsl.com>; Tue, 8 Mar 2011 13:14:27 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id EE5803A6359 for <tls@ietf.org>; Tue, 8 Mar 2011 13:14:26 -0800 (PST)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p28LFe8n021498; Tue, 8 Mar 2011 16:15:40 -0500
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
To: "'marsh@extendedsubset.com'" <marsh@extendedsubset.com>
Date: Tue, 08 Mar 2011 16:15:40 -0500
Thread-Topic: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx
Thread-Index: Acvd00Iz7EVKSIimSDe4r05ByktRaAAAqksu
In-Reply-To: <4D7697E2.2060506@extendedsubset.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-08_08:2011-03-08, 2011-03-08, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103080141
Message-Id: <20110308211426.EE5803A6359@core3.amsl.com>
Cc: "'tls@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 21:14:28 -0000

The thing is - we don't know. If such an attack is found - the algorithm is certifiably broken for these applications (but not as a hash!). As it is - it's just a set of conjectures and assertions on BOTH sides: "we think/hope SHA is..." Vs "it was not a design consideration so maybe SHA isn't...".

--
Regards,
Uri

----- Original Message -----
From: Marsh Ray [mailto:marsh@extendedsubset.com]
Sent: Tuesday, March 08, 2011 03:56 PM
To: Blumenthal, Uri - 0668 - MITLL
Cc: 'tls@ietf.org' <tls@ietf.org>
Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

On 03/08/2011 01:36 PM, Blumenthal, Uri - 0668 - MITLL wrote:
> In general - since pseudorandom-ness of the output was NOT a design
> principle or criteria of hash functions (until SHA3) - truncating
> hash output is problematic from crypto point because you cannot
> reasonably assume that all the output bits have the "entropy" spread
> over them equally.

But if you can find a systematic way to generate patterns in the output, 
then you have a publication-worthy attack on the function. E.g. if you 
have a way to cause any specific bit position of the output of SHA-256 
to be a '0' 75% of the time, then you have reduced it to a 255.2-bit 
function. (Hilarity ensued when this turned out to be case with RC4).

The TLS doesn't use a raw hash function though. It doesn't even use a 
raw HMAC. It uses recursive application of an HMAC to generate an 
arbitrary amount of output, essentially making a stream cipher. This is 
probably the most conservative aspect of TLS's design, making me a big fan.

For TLS 1.2 it's:

     verify_data
        PRF(master_secret, finished_label, Hash(handshake_messages))
           [0..verify_data_length-1];

     PRF(secret, label, seed) = P_<hash>(secret, label + seed)

     P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + ...

     A(0) = seed
     A(i) = HMAC_hash(secret, A(i-1))

Each HMAC represents two hash function invocations, each SHA-256 
represents 64 rounds.

So before they are used to generate the first block of output, the 
handshake_messages are hashed something like 5 times mixing in 
additional pseudorandom key material all but the first time.

Don't get me wrong, I think 96 bits is too short and is probably a 
holdover from the days when we (wisely) didn't trust our ability to 
design hash functions. But insufficient diffusion does not look like a 
problem.

- Marsh