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

Russ Housley <housley@vigilsec.com> Tue, 02 June 2020 20:59 UTC

Return-Path: <housley@vigilsec.com>
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 E77203A0FE7 for <cfrg@ietfa.amsl.com>; Tue, 2 Jun 2020 13:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 36d-RJI9Ot2V for <cfrg@ietfa.amsl.com>; Tue, 2 Jun 2020 13:59:29 -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 D9F7C3A0FE6 for <cfrg@irtf.org>; Tue, 2 Jun 2020 13:59:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CB64E300B65 for <cfrg@irtf.org>; Tue, 2 Jun 2020 16:59:25 -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 tk1MKqMpm66i for <cfrg@irtf.org>; Tue, 2 Jun 2020 16:59:24 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 26255300A51 for <cfrg@irtf.org>; Tue, 2 Jun 2020 16:59:24 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 2 Jun 2020 16:59:25 -0400
References: <3F99CED3-A810-4CF6-98AC-A55E29000D1F@vigilsec.com> <MN2PR11MB3936EF98AC1A6E300AF0D020C1D30@MN2PR11MB3936.namprd11.prod.outlook.com> <FA7FE22E-385D-4A3F-A668-658BD8BAD049@vigilsec.com>
To: IRTF CFRG <cfrg@irtf.org>
In-Reply-To: <FA7FE22E-385D-4A3F-A668-658BD8BAD049@vigilsec.com>
Message-Id: <FAD5BB24-AE16-4E10-8585-C50D1616F3C0@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Gcx4hT-5122iJNCgi_fIcXlx7kQ>
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: Tue, 02 Jun 2020 20:59:31 -0000

Is anyone else excited about the SHA256-192 parameter values?

Russ



> On May 14, 2020, at 2:07 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> I think that the SUIT WG would find the SHA256-192 parameter values very useful, like right away.  Is there a way to expedite the code point assignment for these?  If test vectors are needed, I am willing to help generate them.
> 
> Russ
> 
> 
>> On Apr 23, 2020, at 5:18 PM, Scott Fluhrer (sfluhrer) <sfluhrer=40cisco.com@dmarc.ietf.org> wrote:
>> 
>>> -----Original Message-----
>>> From: Russ Housley <housley@vigilsec.com>
>>> Sent: Thursday, April 23, 2020 3:01 PM
>>> To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>
>>> Cc: IRTF CFRG <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.
>> 
>>> 
>>> 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.
>> 
>>> 
>>> 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.
>> 
>>> 
>>> Russ
>>> 
>> 
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>