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

"Dang, Quynh" <quynh.dang@nist.gov> Sun, 05 July 2015 12:15 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 E4A7B1A1B79 for <tls@ietfa.amsl.com>; Sun, 5 Jul 2015 05:15:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Wa0t6h--YICb for <tls@ietfa.amsl.com>; Sun, 5 Jul 2015 05:15:06 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800D81A1B74 for <tls@ietf.org>; Sun, 5 Jul 2015 05:15:06 -0700 (PDT)
Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.207.19; Sun, 5 Jul 2015 12:15:05 +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; Sun, 5 Jul 2015 12:15:05 +0000
From: "Dang, Quynh" <quynh.dang@nist.gov>
To: "wwhyte@securityinnovation.com" <wwhyte@securityinnovation.com>
Thread-Topic: [TLS] TLS 1.3 draft-07 sneak peek
Thread-Index: AQHQs4OCiSVGDnhMFEq7N51zJUqqfJ3KAuGAgAADLYCAAAVUgIAASwuAgAAf7wCAAAYlAIAABY0AgAAtxACAAKSNgIAAVK+AgAEi6YY=
Date: Sun, 05 Jul 2015 12:15:04 +0000
Message-ID: <BN1PR09MB124F77BAC56087A41761F3DF3940@BN1PR09MB124.namprd09.prod.outlook.com>
References: <CAE3-qLREFyP34PkKbospPZGEeXDi33J=B3etN1bG0ncCvX4eZw@mail.gmail.com> <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> <CACsn0cm5z=m4QY5KU_J2vDTxK5Z0FRBHDDj+MOiLSizzjLCb_A@mail.gmail.com>, <CAE3-qLQFSbtV8ZG7FMzfBbS8toH403gr7yW0U4WSHMtjX4chdw@mail.gmail.com>
In-Reply-To: <CAE3-qLQFSbtV8ZG7FMzfBbS8toH403gr7yW0U4WSHMtjX4chdw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-originating-ip: [129.6.222.71]
x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:CGqwDbX7lgupVN9lwkH2lzh+H7VvDLdomZJsO0aBzUbqV5gjVZTHOk33VbHVKW7KipncJejHlxqjMF+x/5MyURTw6akCKSDtSCbdavvdD+f5EUfNtdI80Uxt5o2n78pWZ0Oa8yXlRBkmsOIdwzoC+Q==; 24:nkjCieeLrPrKBb0McAMPsDTgu2Tm2moHi6oLGDpW51h3DUQfDbqRHUz5DSWD9XjsMBZ9EBmJ88C2wUk7fD1qqdFlk8TVD4HjLlZCeh11cZo=; 20:GVWFPYXStH9OnPKNfxNYjLVDqdN0Tbj/VTilYR0HTj4K/13ZDTWhQN2EvgxeC3tv1xhkLQKy/hbzE3ghU3FYxQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122;
x-microsoft-antispam-prvs: <BN1PR09MB122F9266D527DDA3C26C137F3940@BN1PR09MB122.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:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122;
x-forefront-prvs: 062899525A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(24454002)(243025005)(377454003)(106116001)(5003600100002)(77156002)(62966003)(19625215002)(33656002)(19580395003)(19580405001)(189998001)(99286002)(5002640100001)(76576001)(93886004)(5001960100002)(122556002)(2501003)(92566002)(40100003)(110136002)(2950100001)(66066001)(74316001)(5001920100001)(16236675004)(16297215004)(46102003)(2900100001)(19617315012)(86362001)(102836002)(15975445007)(50986999)(2656002)(2351001)(77096005)(19627405001)(87936001)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124F77BAC56087A41761F3DF3940BN1PR09MB124namprd_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2015 12:15:04.9459 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/-u81w5WwdT2NO8R7wgNlcazjLr8>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Sun, 05 Jul 2015 12:15:09 -0000

In order for the attack to work, I will have to find a collision for the whole output of the compression function of the first hash function.


The attack works for MD5 || SHA1, SHA1 || SHA-256 etc...But, it does not work for the construction Martin described which provides the same security level of SHA-256.


Quynh.


________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Quynh Dang <quynh97@gmail.com>
Sent: Saturday, July 4, 2015 2:34 PM
To: mrex@sap.com
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek

Hi Martin,

Right. The attack does not work for truncated hashes (or wide-pipe hashes) where hash outputs are smaller than their internal chaining hash values.

Quynh.

On Sat, Jul 4, 2015 at 9:31 AM, Watson Ladd <watsonbladd@gmail.com<mailto:watsonbladd@gmail.com>> wrote:
But these assertions below are not what the paper actually claims!
It's important to actually read the paper, and see that the claims
apply to hash functions of a particular form, namely iterated ones.
The functions mentioned in your counterexample are not iterated hash
functions in the sense of the paper.

Nor, if you believe that the designers of TLS got ciphersuite
negotiation correct, is the claimed "vulnerability" a vulnerability.
If the security of the scheme used by A and B was the strongest in the
intersection, having MD5 based schemes would be fine so long as
everyone had SHA-256 based ones. But we know now that this result
isn't true. (There is an added wrinkle, where a scheme based on a
sufficiently weak hash function will break the negotiation)

On Fri, Jul 3, 2015 at 8:42 PM, Martin Rex <mrex@sap.com<mailto:mrex@sap.com>> wrote:
> 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<mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls



--
"Man is born free, but everywhere he is in chains".
--Rousseau.