Re: [Cfrg] draft-fluhrer-lms-more-parm-sets-01

"Dang, Quynh H. (Fed)" <quynh.dang@nist.gov> Fri, 24 April 2020 16:44 UTC

Return-Path: <quynh.dang@nist.gov>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A753A0EA9 for <cfrg@ietfa.amsl.com>; Fri, 24 Apr 2020 09:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 MoHbCxHLJgoD for <cfrg@ietfa.amsl.com>; Fri, 24 Apr 2020 09:44:33 -0700 (PDT)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2139.outbound.protection.outlook.com [40.107.89.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F733A0E58 for <cfrg@irtf.org>; Fri, 24 Apr 2020 09:44:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NsG1BFJ6zuGDhsmCJsZoSsUI+PIicFgMhL8WeFxDKPEECkKf9nKM0g99fm3okjjOY8wLW+JVArcaVjdq7rP6ztiz0lAPaxVeFkmW66xmD771oNRXaZCHwUbKM+Ggte8ahM1DGnyjBdD0B7i6haknpv8fjZEgMi+rYe8KnNBZPOSg6Dn/848O3p8oLWJ4bCfBT6xJToSMcUjA3j2PR6ggYPLM+kNsOekFQiwvAzuxzLLUe1xbCOYjSdHTWQxzKnv+ztOMh+UWCpQUEmvbejodzqKmFwpdYqOJC5pZUcgRfsWrLDiYyliYuwZQTnDVZMwJH3aDaDD8MfIeYv/8cjq7Tw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qUkCAHH0M2IbSlx2SeaSodXHuaaEIMj66p+y9Y/9KRI=; b=TKgBI83cmqL2xPd93PfTOrG47rcrXzrhS0DeRJLQk+gKhPrICjAndWkX2RKUDwG9WW/KDFx/WPqgq07A8LZyHqPlIXmDeLpFPoDV++zKAvbihjEeNNwX+HqRhZcALFyW45BwB0ROjFuZEHaXzIlB085fcwdbpcpvgcDGewpHggoeL3OsY2xFI5B5ZXHNA/mBZ7AQBg7o7MZeYnJ68a24LYTqXcXQBa0iM6qpHtuF2rcBfiVPIlRJC1o1D1EAlO82QZJc79DFKpqU+Pxp3f/whFWesuWl0vBchkXB4iw9CPkocIc+c61ORncP4QhKgHF65scin5UnpSabG5ZbKn2vRQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qUkCAHH0M2IbSlx2SeaSodXHuaaEIMj66p+y9Y/9KRI=; b=pmGeajvBoo/sLoHBlAnCmC8aQygJShBTyhQPLtYTDuPSNbD6UqkiBiF/VFmXvYOy2B+vFK30CAmK7BqlQkSBnIsr+M/tfYDc9l8TGpkAwP++rwAKEEunP6Y/UYz6W0xQqx+SVwbo8kPdW8mkfT2+Ipl1LbbbmaNzN63wwx+aY0U=
Received: from BL0PR0901MB4321.namprd09.prod.outlook.com (2603:10b6:208:1c8::14) by BL0PR0901MB4356.namprd09.prod.outlook.com (2603:10b6:208:1c9::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 16:44:31 +0000
Received: from BL0PR0901MB4321.namprd09.prod.outlook.com ([fe80::f509:9775:a2c6:401a]) by BL0PR0901MB4321.namprd09.prod.outlook.com ([fe80::f509:9775:a2c6:401a%7]) with mapi id 15.20.2937.012; Fri, 24 Apr 2020 16:44:31 +0000
From: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>
To: Russ Housley <housley@vigilsec.com>
CC: Scott Fluhrer <sfluhrer@cisco.com>, IRTF CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] draft-fluhrer-lms-more-parm-sets-01
Thread-Index: AQHWGbS1Bz3Y6aZdskmJCSq4UbT3zqiHN3uAgADbyWmAAD9+gIAAJYp4
Date: Fri, 24 Apr 2020 16:44:30 +0000
Message-ID: <BL0PR0901MB43210514EB286236FD09945EF3D00@BL0PR0901MB4321.namprd09.prod.outlook.com>
References: <3F99CED3-A810-4CF6-98AC-A55E29000D1F@vigilsec.com> <MN2PR11MB3936EF98AC1A6E300AF0D020C1D30@MN2PR11MB3936.namprd11.prod.outlook.com> <8D7734DD-58AD-450B-B527-73AF004224CD@vigilsec.com> <BL0PR0901MB432179C856F93148CBD664B6F3D00@BL0PR0901MB4321.namprd09.prod.outlook.com>, <408B4950-1A32-4D89-A6B5-80BE807752BE@vigilsec.com>
In-Reply-To: <408B4950-1A32-4D89-A6B5-80BE807752BE@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov;
x-originating-ip: [96.255.220.194]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 91fcdbd5-a20e-462c-9f31-08d7e86ec2f9
x-ms-traffictypediagnostic: BL0PR0901MB4356:
x-microsoft-antispam-prvs: <BL0PR0901MB4356D541AE9EC49CAB4F03ABF3D00@BL0PR0901MB4356.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03838E948C
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR0901MB4321.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(366004)(396003)(376002)(346002)(136003)(64756008)(66476007)(26005)(66446008)(66946007)(76116006)(7696005)(4326008)(2906002)(71200400001)(186003)(8676002)(81156014)(86362001)(8936002)(53546011)(33656002)(54906003)(6506007)(52536014)(55016002)(66556008)(6916009)(478600001)(19627405001)(316002)(9686003)(5660300002)(966005); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wFKGnR12qBqMJ9+rejjbFk9UDUoK5bSBHpPtZU5bW59RV2UDEwycB/gQnF6D8ffU3FQgAJ/35yl1pQxblz4MuWQcybVn8xnYQFjKLSVFpZb9yRUPixRJu7jMWN/8J5l+oo5s19zsFH+De5vVAv4dItHtYAgUUrnFLuyQqEPDOLXf7Ef5vtMi+rNqZ7rAqsB3b+kF90oTAjN3Umwr92POUhT06MYQswkr6wuTG40K0/nvW1vg+8FtrAWljguaZNN/eatldaQ/h8xNwLycuMwb+7zKnWH0P2rYURPPE6DFJSnC4C9Nll08Odd6F02OM+M/xCKB4bIDnUDXINBDyCi12Fc4DzvdNy7EywXpsc09IZnuw76VjTgvnddphasb9wzU92Jzi2emDbiuolpqToIW09o4wQ/5Z7Zpf2mmYQIDYgKceeoQZjT7tXUQsWnwQ+oy7/uiULac9Y6M7AjgoIzKlVxaTtpc4qmEzYCyS3retNQvuqUNM9bqfoQISVII69pFjThogRWzlg7Ls36AqtszXA==
x-ms-exchange-antispam-messagedata: sAXVUwvE2kVZjzoXT8gJttb20MYtNilTwLXXhZrtk92/PSyg93GFCVu5/mhloa8GuxrFKgNGeVedhnP4BCs1c1NzVMGFO2UZRkoYQAKhrZRtQDc7DRjNK0U39Zx2TInYCzIHdUoCq3P2aRWe+Zmbtg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR0901MB43210514EB286236FD09945EF3D00BL0PR0901MB4321_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 91fcdbd5-a20e-462c-9f31-08d7e86ec2f9
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 16:44:30.8970 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NpviKsQ9NmECe6+QzEvNYj1yquuU4zJiQd5wGcCToN31KHIMBlPOZy7mtyTXKqUc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB4356
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6PwKF3_6wYR9lzLqxHjFdURV7DA>
Subject: Re: [Cfrg] draft-fluhrer-lms-more-parm-sets-01
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 16:44:35 -0000

Hi Russ,

If you use SHA3-256 to get a 192-bit version, you will need to run SHA3-256 (output is 256 bits), then do a truncation step to get a 192-bit value. With SHAKE256/192, you just run SHAKE256 with the output being 192 bits; there is no extra truncation step needed.

SHA3-256 is intended for being used as a fixed output length hash function.

Therefore, SHAKE256/192 makes more sense than SHA3-256 with an additional truncation step to get a 192-bit output.

So, (SHAKE256/192 + SHAKE256/256) makes more sense than both of these options: (SHA3-256 + SHA3-256/192) and (SHA3-256 + SHAKE256/192).

Regards,
Quynh.

Regards,
Quynh.

________________________________
From: Russ Housley <housley@vigilsec.com>
Sent: Friday, April 24, 2020 10:17 AM
To: Dang, Quynh H. (Fed) <quynh.dang@nist.gov>
Cc: Scott Fluhrer <sfluhrer@cisco.com>; IRTF CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] draft-fluhrer-lms-more-parm-sets-01

Quynh:

I do not understand number 2.  Can you please say more?  I think it makes sense if the output is greater than the size of the hash function, but exactly the same or less.

The difference it primarily the padding at the end of the message:

SHA3-256(M) = KECCAK[512](M || 01, 256)
SHAKE256(M, d) = KECCAK[512](M || 1111, d)

This answers Uri's question about the performance.  They are essentially the same.

Russ


On Apr 24, 2020, at 6:52 AM, Dang, Quynh H. (Fed) <quynh.dang=40nist.gov@dmarc.ietf.org<mailto:quynh.dang=40nist.gov@dmarc.ietf.org>> wrote:

Hi Russ and all,

The reasons for specifying SHAKE256/256 and SHAKE256/192 are followings:

1) SHA3-256 and SHAKE256/256 are the same except different paddings to make them different functions.

2) If we use SHA3-256, then we would use SHA3-256/192 or SHAKE256/192 for the 192-bit version. SHA3-256 (or SHA3-512 etc...) is intended to be used as a fixed output length hash function. Therefore, it makes more sense to use SHAKE256/192 than to use SHA3-256/192.

So, it makes more sense to use SHAKE256/256 and SHAKE256/192 than to use SHA3-256 and SHAKE256/192.

3) SHAKE256 has already been adopted for CMS and PKIX. So, it makes more sense to continue to use SHAKE256 than to use another variant of it such as SHA3-256.

Regards,
Quynh.
________________________________
From: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Sent: Thursday, April 23, 2020 5:23 PM
To: Scott Fluhrer <sfluhrer@cisco.com<mailto:sfluhrer@cisco.com>>
Cc: Dang, Quynh H. (Fed) <quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>>; IRTF CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>
Subject: Re: draft-fluhrer-lms-more-parm-sets-01

Thanks for the prompt reply Scott.

> On Apr 23, 2020, at 5:18 PM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com<mailto:sfluhrer@cisco.com>> wrote:
>
>> -----Original Message-----
>> From: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
>> Sent: Thursday, April 23, 2020 3:01 PM
>> To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com<mailto:sfluhrer@cisco.com>>
>> Cc: IRTF CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>
>> Subject: draft-fluhrer-lms-more-parm-sets-01
>>
>> Scott:
>>
>> Thanks for your talk on this draft yesterday.  It raised a few questions.
>>
>> 1) SHA256-192:  I like it.  Does the size of I change?  My guess is that it is still
>> 16 bytes, but I want to be sure.
>
> The size of I remains at 16 bytes.  The reason I is there is to address potential multitarget attacks; that is, where someone attacks two different public keys by hashing a single value and seeing if it matched a value from either Merkle tree/Winternitz chain.  Because two different public keys will have different I values, this doesn't yield an advantage (as the attempted hash will need to select a specific I value.
>
> This protection doesn't have anything to do with the hash size, and so it does not change.

Thanks.  This is as I expected.

>> 2) SHAKE256-256 and SHAKE256-192:  Why use an Extendable-Output
>> Function (XOF)?  Since the output in the application is always 256 bits or 192
>> bits, the normal reason for picking an XOF does not seem relevant.
>
> That's actually a Dang question; he suggested we add it, so I copied him.
>
> On the other hand, SHAKE256 and SHA3-256 are almost the same (differing only in the end-of-message padding), and so I don't believe it really matters.

Yes, you are obviously correct about the extra suffix bits, and I look forward to hearing from Quynh.


>> 3) Temporary code points: Why do you have collisions?  For example,
>> LMOTS_SHA256_N24_W1 and LMS_SHA256_M24_H5 are the same, and RFC
>> 8554 avoided overlaps between LMS and LMOTS code points.
>
> They're not a collision; they are in different spaces  The fact that RFC 8554 happened to avoid collisions is just an accident of history (originally, that draft defined 128 bit hashes as well, and the LMSOT code points for 128 bits hashes came after the 256 bit hashes, and the LMS code points for 128 bit hashes came first.  We dropped the 128 bit hashes, but left the 256 bit code points unchanged, resulting in the current assignments.

Okay.

Russ

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org<mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&data=02%7C01%7Cquynh.dang%40nist.gov%7C6ac7ab538a714decc34308d7e85a421f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637233346677116474&sdata=y%2Blji5zAiSvjacp5HUpFWxHNG9PTX4RN%2F2w0Q0t53A8%3D&reserved=0>