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

Tim Hollebeek <tim.hollebeek@digicert.com> Wed, 27 March 2019 09:08 UTC

Return-Path: <tim.hollebeek@digicert.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 D9BD912028A for <spasm@ietfa.amsl.com>; Wed, 27 Mar 2019 02:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=LCTtIhiJ; dkim=pass (1024-bit key) header.d=digicert.com header.b=NVaPJIe5
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 bcLLwIG-ZutL for <spasm@ietfa.amsl.com>; Wed, 27 Mar 2019 02:08:43 -0700 (PDT)
Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78E0120285 for <spasm@ietf.org>; Wed, 27 Mar 2019 02:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1553677715; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V5vmV/9PJopKJNXfE+VsRqdC5Ek7wLI2wCWxIohOxE0=; b=LCTtIhiJLqzUJxTRJ4o6TtqhQRSXRWI+71YVmzsQXYch0AUR76qvGirs4pONOU0X49sAsgW+ldgQEXybsE0f/6m2J/fyg2WkTojFS457uyCVi68Zl1wpYvh5mPNxizhPHov1izzgE6P0zOX77Z6w3gK0TwwSscNq9NysegFsB98=
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2050.outbound.protection.outlook.com [104.47.44.50]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-0my11L4mOFOWSnELvqHkyw-1; Wed, 27 Mar 2019 05:08:33 -0400
X-MC-Unique: 0my11L4mOFOWSnELvqHkyw-1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V5vmV/9PJopKJNXfE+VsRqdC5Ek7wLI2wCWxIohOxE0=; b=NVaPJIe5B0SyS7xzBEnsdeg/yx6lC9fa+lLAaumGWdMifg9VLHznrMTEyndN9VM/dNOb7PqMD7LrXORFjnd8A+nh59t/yTYQKEQx3NAlfCymz7zXF5NJlo63ZNybbgOsre1wNEo86Nqwfd+xlG4Gy2F5x6zaQmo7VbvRbtLk7GI=
Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1809.namprd14.prod.outlook.com (10.171.176.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.16; Wed, 27 Mar 2019 09:08:31 +0000
Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::294e:1bc:bb2b:e728]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::294e:1bc:bb2b:e728%5]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 09:08:31 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: "Dang, Quynh (Fed)" <quynh.dang=40nist.gov@dmarc.ietf.org>, Jim Schaad <ietf@augustcellars.com>, "'Scott Fluhrer (sfluhrer)'" <sfluhrer@cisco.com>, 'SPASM' <spasm@ietf.org>
Thread-Topic: [lamps] Side-channel attack on multi-level trees and key generation of LMS.
Thread-Index: AQHU49VXx21KHECH1UWEyX+/NMZuuKYd5ZWAgAAMQQCAABNAAIAABCUAgAAMzgCAAAI0gIABGDAw
Date: Wed, 27 Mar 2019 09:08:31 +0000
Message-ID: <BN6PR14MB11067DDDC2C016B29D53E54E83580@BN6PR14MB1106.namprd14.prod.outlook.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> <026b333ae64b45abb031a537366512df@XCH-RTP-006.cisco.com>, <04c001d4e3ee$dc6a1b90$953e52b0$@augustcellars.com> <BN8PR09MB360492F2741D92172B0AEA3EF35F0@BN8PR09MB3604.namprd09.prod.outlook.com>
In-Reply-To: <BN8PR09MB360492F2741D92172B0AEA3EF35F0@BN8PR09MB3604.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com;
x-originating-ip: [31.133.150.157]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2cc30b08-057b-4985-13c9-08d6b293c898
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1809;
x-ms-traffictypediagnostic: BN6PR14MB1809:
x-microsoft-antispam-prvs: <BN6PR14MB1809289AA1C1A931FF368A9483580@BN6PR14MB1809.namprd14.prod.outlook.com>
x-forefront-prvs: 0989A7979C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(136003)(39860400002)(366004)(376002)(346002)(396003)(53754006)(189003)(199004)(68736007)(86362001)(8936002)(71190400001)(71200400001)(316002)(110136005)(186003)(81166006)(26005)(8676002)(81156014)(76176011)(33656002)(6436002)(97736004)(7696005)(229853002)(102836004)(14454004)(256004)(66066001)(99936001)(105586002)(6506007)(53546011)(93886005)(106356001)(305945005)(6246003)(25786009)(966005)(44832011)(53936002)(2906002)(486006)(446003)(99286004)(52536014)(7736002)(6306002)(9686003)(5660300002)(478600001)(11346002)(74316002)(476003)(3846002)(55016002)(6116002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1809; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: l3BzMZiLNNYnB5Th6xf9Ukjrnvue6SlDplwg4BlLub5eN0s0qUfATyO6lhCazV5B8eiu9F32lJkwibvp7DSgTuXJ5ENPIjJ9yGmM0ViuKdhswOsQqzR7znvTT6VMdb4yhQt6zX52L2c05UK0xJgtxu+xZOFB40uYJYBS2tt4nMd6yidz5HIMMLfZyv14kgETGPeIdGpUBiBKL6U6pnTDFyPYj3F7wNUZ8827fru7+A9BhMDhOZTbzDA+TBZ2Cz4XR4RySeKPVSWowgWKI3CrUODF41rvFPAyv2jwU7l672B9gucMX7KdpuGl+wdQK0QsZlSdKn/Qr0CqP0TLeaBNKeBcxSu6j76sh4xP6eeRAcICsqoQa+OgykFzRpi1qiuFCzIKzMUPxPYsplmODtXqRKuwIEFATv72tw9pWQeb4Cg=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0185_01D4E485.06514640"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2cc30b08-057b-4985-13c9-08d6b293c898
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 09:08:31.4169 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1809
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/39cv1eXvgPHoWMMa-CpIdJn_C90>
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:08:57 -0000

Except that a two level tree is not like a big one level tree.

 

For an N node one level tree, you can typically reduce the number of nodes
that need to be managed at a time to 2 x sqrt(N), by using two level trees
and only keeping one subtree around at a time.

 

You also don't have to generate all the subtrees in advance.

 

-Tim

 

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

 

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%7Cdff17ae48c72
44b4d0be08d6b2060b46%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C6368921363
57856166&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.ia
cr.org%2F2018%2F674%2F20180713%3A140821&data=02%7C01%7Cquynh.dang%40nist.gov
%7Cdff17ae48c7244b4d0be08d6b2060b46%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7
C0%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.