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

Russ Housley <housley@vigilsec.com> Wed, 27 March 2019 09:55 UTC

Return-Path: <housley@vigilsec.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 C1E98120292 for <spasm@ietfa.amsl.com>; Wed, 27 Mar 2019 02:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eFW44OTeB5yR for <spasm@ietfa.amsl.com>; Wed, 27 Mar 2019 02:55:03 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D4912028F for <spasm@ietf.org>; Wed, 27 Mar 2019 02:55:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B050C300ADC for <spasm@ietf.org>; Wed, 27 Mar 2019 05:36:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ypv26icJxbGr for <spasm@ietf.org>; Wed, 27 Mar 2019 05:36:41 -0400 (EDT)
Received: from dhcp-9482.meeting.ietf.org (dhcp-9482.meeting.ietf.org [31.133.148.130]) by mail.smeinc.net (Postfix) with ESMTPSA id E9F2E3009FB; Wed, 27 Mar 2019 05:36:40 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <23FADE12-986D-423D-B0C2-6DAF1778E0AD@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F0E218C-C06E-4D67-BAA1-566B29E3D2FA"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 27 Mar 2019 05:54:56 -0400
In-Reply-To: <BN8PR09MB360492F2741D92172B0AEA3EF35F0@BN8PR09MB3604.namprd09.prod.outlook.com>
Cc: SPASM <spasm@ietf.org>
To: Quynh Dang <quynh.dang@nist.gov>
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> <026b333ae64b45abb031a537366512df@XCH-RTP-006.cisco.com> <04c001d4e3ee$dc6a1b90$953e52b0$@augustcellars.com> <BN8PR09MB360492F2741D92172B0AEA3EF35F0@BN8PR09MB3604.namprd09.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/neMjYlKk-eBcFiFfkGCwnjnPOk8>
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: Wed, 27 Mar 2019 09:55:07 -0000

Quynh:

That is not correct. In one big tree, all of the nodes need to be populated to generate the public key.  In a tree of trees, the top-most tree must be populated and then one of the subordinate trees, then a leaf on the top-most tree is used to sign the public key of the subordinate tree.  One does not have to populate the second subordinate tree until the first one is consumed.

Russ


> On Mar 26, 2019, at 12:21 PM, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
> 
> time and memory trade-offs are applicable to both cases. Think the multi-level tree is a tree, like a big 1-level tree. 
> 
> Quynh. 
> From: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org>> on behalf of Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com>>
> Sent: Tuesday, March 26, 2019 12:13:30 PM
> To: 'Scott Fluhrer (sfluhrer)'; 'Dang, Quynh (Fed)'; 'SPASM'
> Subject: Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.
>  
> I understand that, but again there are some trade-offs of memory vs time.  All of the simple tree saving algorithms I have thought of can occasionally require the generation of a large portion of the tree depending on what boundaries one is crossing in the tree, this means that the signing time is not constant.  One can also make gains by doing some pre-computation of expected trees as one goes along.  When you have a tree of trees, one can get lots of speed up by saving the signature for all but the bottom most tree so that only that tree needs to have portions regenerated until you move to a new sub-tree.
>  
> All of these are space/time trade-offs and one needs to understand what the extremes are on both ends before one says that a huge single tree is better or worse than a lot of small trees, even if the number of levels that are created are the same.
>  
> Jim
>  
>  
> From: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com <mailto:sfluhrer@cisco.com>> 
> Sent: Tuesday, March 26, 2019 4:28 PM
> To: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com>>; 'Dang, Quynh (Fed)' <quynh.dang=40nist.gov@dmarc.ietf.org <mailto:quynh.dang=40nist.gov@dmarc.ietf.org>>; 'SPASM' <spasm@ietf.org <mailto:spasm@ietf.org>>
> Subject: RE: [lamps] Side-channel attack on multi-level trees and key generation of LMS.
>  
> 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 <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.szydlo.com%2Ffractal-jmls.pdf&data=02%7C01%7Cquynh.dang%40nist..gov%7Cdff17ae48c7244b4d0be08d6b2060b46%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636892136357856166&sdata=EfECdJowp9SvSbwh7RtHD1OHVA2dBU7I3DF%2FK%2FI7J%2BU%3D&reserved=0>
>  
> From: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com>> 
> Sent: Tuesday, March 26, 2019 11:13 AM
> To: 'Dang, Quynh (Fed)' <quynh.dang=40nist.gov@dmarc.ietf.org <mailto:quynh.dang=40nist.gov@dmarc.ietf.org>>; 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.
>  
> 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%7Cdff17ae48c7244b4d0be08d6b2060b46%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636892136357866162&sdata=MQDZ%2F6NEXUCdvUivnHwRVH0bXgIQb4D5GbCTNovZ3cg%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. 
>  
>  
>  
>  
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org <mailto:Spasm@ietf.org>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>