Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Tue, 26 March 2019 15:27 UTC

Return-Path: <sfluhrer@cisco.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2699212036B for <spasm@ietfa.amsl.com>; Tue, 26 Mar 2019 08:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.511
X-Spam-Level:
X-Spam-Status: No, score=-12.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 JulyfzHyq8Fq for <spasm@ietfa.amsl.com>; Tue, 26 Mar 2019 08:27:43 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EE1120381 for <spasm@ietf.org>; Tue, 26 Mar 2019 08:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18216; q=dns/txt; s=iport; t=1553614062; x=1554823662; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mxAi3Lv5hCQE7w86kAkF98NZiejHk74wsm1G91l7sfE=; b=GPKl3I5v8CtmgVYRkkqK+GiV1T26Zy2+/qqB8cGqjBuFLLiA7oJHRMxh lLK17QmqPp40UrxPNvb5wvRwo9x8sZvxzOvMXNCl7pyF99/8GrfBhauLP wO0wduM00VkUH4b9KbBsoAlgD9cvyFGXJWM4J4YDcb8CUpNI5DUskrA2N 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AsAACGRJpc/4oNJK1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBZYEPgQJogQMnCoVjkWKCDZo2DQEBIoEPXYJeAoUiIjgSAQEDAQEJAQMCbRwMhUoBAQECAi1cAgEIDgMEAQEoBzIUCQgCBAESCIMVBAKBEUwDFQ+uboQwAYNTA4IpgS+IaIJKF4FAP4NuBy4+gmEDARiBTDGFKwOKSiCGJ4dHi2FgCQKHYYtQIZQCiCSBbIENhgaNLAIRFYEuNiENgUlwFYMnCQqBUy0ag0uFFIU/QTEBAQEBjxkybQEB
X-IronPort-AV: E=Sophos;i="5.60,273,1549929600"; d="scan'208,217";a="540014476"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 15:27:41 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QFRfjY031705 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 15:27:41 GMT
Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 11:27:40 -0400
Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 11:27:40 -0400
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Jim Schaad <ietf@augustcellars.com>, "'Dang, Quynh (Fed)'" <quynh.dang=40nist.gov@dmarc.ietf.org>, 'SPASM' <spasm@ietf.org>
Thread-Topic: [lamps] Side-channel attack on multi-level trees and key generation of LMS.
Thread-Index: AQHU49VXPtCcAwv+dECjmnZztrzUW6Yd47nAgABRKwCAABNAAP//vYTQ
Date: Tue, 26 Mar 2019 15:27:40 +0000
Message-ID: <026b333ae64b45abb031a537366512df@XCH-RTP-006.cisco.com>
References: <BN6PR14MB1106140408FFB08553DEAE98835F0@BN6PR14MB1106.namprd14.prod.outlook.com>, <D6AB5830-C69A-44CA-BD63-9B64F92C032E@vigilsec.com> <BN8PR09MB3604C9C7C8609430A58FD99EF35F0@BN8PR09MB3604.namprd09.prod.outlook.com>, <afb437b0d9e14a8097947a25d8422286@XCH-RTP-006.cisco.com> <BN8PR09MB3604324EF9D5BF4E9061F1B4F35F0@BN8PR09MB3604.namprd09.prod.outlook.com> <048d01d4e3e6$625b4980$2711dc80$@augustcellars.com>
In-Reply-To: <048d01d4e3e6$625b4980$2711dc80$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.64.141]
Content-Type: multipart/alternative; boundary="_000_026b333ae64b45abb031a537366512dfXCHRTP006ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.147, xch-rtp-007.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Ktw0KvmrqgC1YIn76ilMtgThVGk>
Subject: Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 15:27:45 -0000

Actually, there are algorithms that are able to generate the next authentication path by storing a comparatively small part of the tree, and using only a relatively small number of leaf node evaluations.  For example, http://www.szydlo.com/fractal-jmls.pdf

From: Jim Schaad <ietf@augustcellars.com>
Sent: Tuesday, March 26, 2019 11:13 AM
To: 'Dang, Quynh (Fed)' <quynh.dang=40nist.gov@dmarc.ietf.org>; Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>; 'SPASM' <spasm@ietf.org>
Subject: RE: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

There is one other factor to compare in terms of how big the tree is.  For a very large tree, if you do not have the resources to keep the entire private key set (or a large subset of it) then you get into the situation where you regenerate the entire private key tree for each and every signature.  This is part of the trade off between small key size and fast signature generation/usage of time.

Jim


From: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> On Behalf Of Dang, Quynh (Fed)
Sent: Tuesday, March 26, 2019 3:04 PM
To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com<mailto:sfluhrer@cisco.com>>; SPASM <spasm@ietf.org<mailto:spasm@ietf.org>>
Subject: Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.


The only downside of 1 level tree is its key generation time comparing to multi-level trees. In situations ( such as a code signing application) where 1, 2 or 3 etc... hours of a key generation time is not a problem, then using a big 1 level tree seems better than using a multi-level tree.



Therefore,  some bigger height numbers for 1-level tree may be desired.



Quynh.

________________________________
From: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com<mailto:sfluhrer@cisco.com>>
Sent: Tuesday, March 26, 2019 9:20:05 AM
To: Dang, Quynh (Fed); SPASM
Subject: RE: [lamps] Side-channel attack on multi-level trees and key generation of LMS.


Irom: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> On Behalf Of Dang, Quynh (Fed)
Sent: Tuesday, March 26, 2019 9:11 AM
To: SPASM <spasm@ietf.org<mailto:spasm@ietf.org>>
Subject: [lamps] Side-channel attack on multi-level trees and key generation of LMS.



Hi all,



Here is the attack I mentioned at the meeting today: https://eprint.iacr.org/2018/674/20180713:140821<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2018%2F674%2F20180713%3A140821&data=02%7C01%7Cquynh.dang%40nist.gov%7C17afe62f6ae74a858cbf08d6b1edc737%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636892032138187826&sdata=9u3pPjSd5ErMGIiBVoyV%2BjwwRyreeZJm4U7ONsQPU5w%3D&reserved=0>.



This is a fault attack (that is, you try to make the signer miscompute something, and then use the miscomputed signature); a signer implementation could implement protections against this (of course, those protections are not free).



I just looked at the LMS's draft, the single tree with height 25 ( 2^25 signatures)  takes only 1.5 hours.



Clarification on this:

  *   The test used 15 cores (and so it used a total of circa 1 core-day)
  *   This was done with a W=8 parameter set.  This makes the signature shorter (1936 bytes in this case), however it does increase the key generation time; a W=4 parameter set would approximately double the signature size, while decreasing the key generation time by circa a factor of 8.





Regards,

Quynh.