Return-Path: 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 EF3473A005B for ; Fri, 24 Apr 2020 11:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 RmXa1iqn_Wrd for ; Fri, 24 Apr 2020 11:24:39 -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 A55803A003D for ; Fri, 24 Apr 2020 11:24:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1848C300AF8 for ; Fri, 24 Apr 2020 14:24:36 -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 VocKCAk9qIsV for ; Fri, 24 Apr 2020 14:24:32 -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 BCF53300435; Fri, 24 Apr 2020 14:24:32 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C122A3B4-BC22-4DF2-A94E-BE3B4A13DBB8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 24 Apr 2020 14:24:34 -0400 In-Reply-To: Cc: Scott Fluhrer , IRTF CFRG To: Quynh Dang References: <3F99CED3-A810-4CF6-98AC-A55E29000D1F@vigilsec.com> <8D7734DD-58AD-450B-B527-73AF004224CD@vigilsec.com> <408B4950-1A32-4D89-A6B5-80BE807752BE@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 18:24:43 -0000 --Apple-Mail=_C122A3B4-BC22-4DF2-A94E-BE3B4A13DBB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks. I understand your argument, but I do not see truncation as a = step. At most, it is a memory copy. Russ > On Apr 24, 2020, at 12:44 PM, Dang, Quynh H. (Fed) = wrote: >=20 > Hi Russ, >=20 > 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.=20 >=20 > SHA3-256 is intended for being used as a fixed output length hash = function.=20 >=20 > Therefore, SHAKE256/192 makes more sense than SHA3-256 with an = additional truncation step to get a 192-bit output. >=20 > So, (SHAKE256/192 + SHAKE256/256) makes more sense than both of these = options: (SHA3-256 + SHA3-256/192) and (SHA3-256 + SHAKE256/192).=20 >=20 > Regards, > Quynh.=20 >=20 > Regards, > Quynh.=20 >=20 > From: Russ Housley > > Sent: Friday, April 24, 2020 10:17 AM > To: Dang, Quynh H. (Fed) > > Cc: Scott Fluhrer >; = IRTF CFRG > > Subject: Re: [Cfrg] draft-fluhrer-lms-more-parm-sets-01 > =20 > Quynh: >=20 > 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. >=20 > The difference it primarily the padding at the end of the message: >=20 > SHA3-256(M) =3D KECCAK[512](M || 01, 256) > SHAKE256(M, d) =3D KECCAK[512](M || 1111, d) >=20 > This answers Uri's question about the performance. They are = essentially the same. >=20 > Russ >=20 >=20 >> On Apr 24, 2020, at 6:52 AM, Dang, Quynh H. (Fed) = > wrote: >>=20 >> Hi Russ and all, >>=20 >> The reasons for specifying SHAKE256/256 and SHAKE256/192 are = followings: >>=20 >> 1) SHA3-256 and SHAKE256/256 are the same except different paddings = to make them different functions.=20 >>=20 >> 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.=20 >>=20 >> So, it makes more sense to use SHAKE256/256 and SHAKE256/192 than to = use SHA3-256 and SHAKE256/192. >>=20 >> 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.=20 >>=20 >> Regards, >> Quynh.=20 >> From: Russ Housley > >> Sent: Thursday, April 23, 2020 5:23 PM >> To: Scott Fluhrer > >> Cc: Dang, Quynh H. (Fed) >; IRTF CFRG > >> Subject: Re: draft-fluhrer-lms-more-parm-sets-01 >> =20 >> Thanks for the prompt reply Scott. >>=20 >> > On Apr 23, 2020, at 5:18 PM, Scott Fluhrer (sfluhrer) = > wrote: >> >=20 >> >> -----Original Message----- >> >> From: Russ Housley > >> >> Sent: Thursday, April 23, 2020 3:01 PM >> >> To: Scott Fluhrer (sfluhrer) > >> >> Cc: IRTF CFRG > >> >> Subject: draft-fluhrer-lms-more-parm-sets-01 >> >>=20 >> >> Scott: >> >>=20 >> >> Thanks for your talk on this draft yesterday. It raised a few = questions. >> >>=20 >> >> 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. >> >=20 >> > 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. >> >=20 >> > This protection doesn't have anything to do with the hash size, and = so it does not change. >>=20 >> Thanks. This is as I expected. >>=20 >> >> 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. >> >=20 >> > That's actually a Dang question; he suggested we add it, so I = copied him. >> >=20 >> > 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. >>=20 >> Yes, you are obviously correct about the extra suffix bits, and I = look forward to hearing from Quynh. >>=20 >>=20 >> >> 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. >> >=20 >> > 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. >>=20 >> Okay. >>=20 >> Russ >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg = --Apple-Mail=_C122A3B4-BC22-4DF2-A94E-BE3B4A13DBB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks.  I understand your argument, but I do not see = truncation as a step.  At most, it is a memory copy.

Russ


On Apr 24, 2020, at 12:44 PM, Dang, Quynh H. = (Fed) <quynh.dang@nist.gov> wrote:

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) =3D KECCAK[512](M || 01, 256)
SHAKE256(M, d) =3D 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=3D40nist.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>
Sent: Thursday, April 23, 2020 = 5:23 PM
To: Scott Fluhrer <sfluhrer@cisco.com>
Cc: Dang, Quynh H. (Fed) = <quynh.dang@nist.gov>; IRTF CFRG <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> 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.

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
https://www.irtf.org/mailman/listinfo/cfrg

= --Apple-Mail=_C122A3B4-BC22-4DF2-A94E-BE3B4A13DBB8--