Re: [TLS] TLS 1.3 draft-07 sneak peek

"Dang, Quynh" <quynh.dang@nist.gov> Sat, 04 July 2015 12:30 UTC

Return-Path: <quynh.dang@nist.gov>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FDA1A8AB3 for <tls@ietfa.amsl.com>; Sat, 4 Jul 2015 05:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.399
X-Spam-Level:
X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OsXM7ChvuSR for <tls@ietfa.amsl.com>; Sat, 4 Jul 2015 05:30:38 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C501A89F2 for <tls@ietf.org>; Sat, 4 Jul 2015 05:30:38 -0700 (PDT)
Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB121.namprd09.prod.outlook.com (10.255.200.145) with Microsoft SMTP Server (TLS) id 15.1.207.19; Sat, 4 Jul 2015 12:30:19 +0000
Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0207.004; Sat, 4 Jul 2015 12:30:19 +0000
From: "Dang, Quynh" <quynh.dang@nist.gov>
To: "mrex@sap.com" <mrex@sap.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] TLS 1.3 draft-07 sneak peek
Thread-Index: AQHQs4OCiSVGDnhMFEq7N51zJUqqfJ3KAuGAgAADLYCAAAVUgIAASwuAgAAf7wCAAAYlAIAABY0AgAAtxACAAIyF0w==
Date: Sat, 04 Jul 2015 12:30:19 +0000
Message-ID: <BN1PR09MB124CE159C28C9B617BB2E07F3950@BN1PR09MB124.namprd09.prod.outlook.com>
References: <CAE3-qLREFyP34PkKbospPZGEeXDi33J=B3etN1bG0ncCvX4eZw@mail.gmail.com>, <20150704034218.613C41A1B3@ld9781.wdf.sap.corp>
In-Reply-To: <20150704034218.613C41A1B3@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: sap.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [129.6.219.222]
x-microsoft-exchange-diagnostics: 1; BN1PR09MB121; 5:T6FlKp+FBACXSzLPgIKipmMqMBLnR7vsagEFtsOobq09+TKFNpFuxIuq87YeQfCF6jpJ/ME6nYKRXYD0f4uYPpQGaTt+p4Yp4jeROuSeHNO0GVbtFlsKlsATwIl1r0KWOwAVa4H6Vwc1unhtrSxUmg==; 24:h8zLnWzwwshyGTUuexRBOloY+1myrtPICCy1LWcpDVLlEs16FvXKvZPKTEollCT0YaOnb9m81jTc/0sxAUNeEat/+VAeorVsuG6cCaC2oQI=; 20:mzBgDDSLHynYs/NpmmnIo4mhZU0o3VTwiVGEZHNwe1awCOm0k5VX/D2OmyJSPvxou2a6myhmbrAnUPqGPPlpHg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB121;
x-microsoft-antispam-prvs: <BN1PR09MB1214043D1F423BF70BB9D37F3950@BN1PR09MB121.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR09MB121; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB121;
x-forefront-prvs: 06274D1C43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(243025005)(51704005)(106116001)(19580395003)(86362001)(66066001)(2501003)(50986999)(76176999)(19627405001)(5001770100001)(92566002)(46102003)(19625215002)(33656002)(99286002)(2950100001)(76576001)(5003600100002)(2656002)(189998001)(19617315012)(122556002)(107886002)(19580405001)(40100003)(54356999)(5001960100002)(2900100001)(87936001)(5002640100001)(74316001)(77096005)(102836002)(77156002)(62966003)(16236675004)(15975445007)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB121; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124CE159C28C9B617BB2E07F3950BN1PR09MB124namprd_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2015 12:30:19.1971 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB121
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_FY1fa9BigodfQvop4305GBP-DE>
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 04 Jul 2015 12:30:42 -0000

Hi Martin,

I talked about this issue at the interim meeting in Denver last year. A lot of people there who were very good at crypto, but were not aware of this issue.  In another word, nobody knows all. So, being not aware of something is common to everyone.

Let me explain one of your examples and I hope that will help to make the issue clear.

"OK, here are my algorithms F and G:

  F= sha-256, truncated to bits 0..95 of the output
  G= sha-256, truncated to bits 96..256 of the output"

It takes approximately 2^48 operations to find a block X and X' (X and X' can be any blocks) as long as their 96-bit hash values ( F) are the same.

It takes approximately 2^80 operations to find a block N (N can be any block) so that 160-bit hash values (G) of X|| N and X'|| N are the same.

So, the work required to find a collision for G is  2^80 and the work required to find a collision for F || G is 2^48 + 2^80 and 2^48 is like nothing when being compared to 2^80.

Happy the 4th of July!

Quynh.

________________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Martin Rex <mrex@sap.com>
Sent: Friday, July 3, 2015 11:42 PM
To: Quynh Dang
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek

Quynh Dang wrote:
> The ineffectiveness issue of cascading hashes has been widely known for a
> long time ago.
>
> Find block X and block X' which have collided hash for SHA1 which takes
> around 2^70 operations or possibly less.
>
> Finding a block N for which X|| N and X' || N have collided hash for MD5
> which is expected to have very low complexity (finding collision for MD5).
>
> Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5
> require about the same computational complexity.


The previously mentioned paper

http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf

describes the issue for two arbitrary hash algorithms F and G
with bit sizes nF and nG and you say this applies to

  F= md5  nF=128 bit
  G= sha1 nG=160 bit

  and that the security of F||G would be no stronger than the larger
  of the two (G alone, nG=160).


OK, lets take two other hash algorithms F and G, and even use
a weaker algorithm F with nF=96 and G with nG=160.
The assertion is, that he security of F||G would still be only 160.

OK, here are my algorithms F and G:

  F= sha-256, truncated to bits 0..95 of the output
  G= sha-256, truncated to bits 96..256 of the output

Now if your original assertion is true, then the strength of
F(m)||G(m) which curiously happens to be identical to the output of
sha256 for the message (m) has a security of only 160 bits?

Or lets look at a concatenation of 8 hashes of 32-bits each.

F=sha-256, truncated to bits 0..31 of the output
...



-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls