[CFRG] draft-fluhrer-lms-more-parm-sets

Russ Housley <housley@vigilsec.com> Tue, 11 May 2021 19:19 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6B1943A2341 for <cfrg@ietfa.amsl.com>; Tue, 11 May 2021 12:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7OswOq7qsw9Z for <cfrg@ietfa.amsl.com>; Tue, 11 May 2021 12:19:48 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FB13A2340 for <cfrg@irtf.org>; Tue, 11 May 2021 12:19:48 -0700 (PDT)
Received: from localhost (localhost []) by mail.smeinc.net (Postfix) with ESMTP id 73796300AA6 for <cfrg@irtf.org>; Tue, 11 May 2021 15:19:46 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([]) by localhost (mail.smeinc.net []) (amavisd-new, port 10026) with ESMTP id TL9AoURuihWt for <cfrg@irtf.org>; Tue, 11 May 2021 15:19:39 -0400 (EDT)
Received: from [] (pool-141-156-161-153.washdc.fios.verizon.net []) by mail.smeinc.net (Postfix) with ESMTPSA id 38B1B3004AC for <cfrg@irtf.org>; Tue, 11 May 2021 15:19:39 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB7B0D73-1777-4924-85BD-C60BCBC9A636"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
Date: Tue, 11 May 2021 15:19:38 -0400
References: <BN7PR11MB264152C19ECEFD79A61E7DDDC18F9@BN7PR11MB2641.namprd11.prod.outlook.com> <CAMr0u6nG-APMtEOn=xYdjBF0q3So6UEp-Nu0aB8tNEr154KNoA@mail.gmail.com> <EA7EDC73-C399-4089-B89A-0B6EF89EDC21@callas.org> <BN7PR11MB2641B951100EB5C8AD3023A2C18A9@BN7PR11MB2641.namprd11.prod.outlook.com> <CAMr0u6m_w_g5tofgW6=Yo1im13TW+9F2uBAX90zsp+ycjWCy5g@mail.gmail.com>
To: IRTF CFRG <cfrg@irtf.org>
In-Reply-To: <CAMr0u6m_w_g5tofgW6=Yo1im13TW+9F2uBAX90zsp+ycjWCy5g@mail.gmail.com>
Message-Id: <2E3C2B18-22E1-4C10-99BE-CA09298F5472@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/mHicV3emFJbDggXYO0pibKA5cfU>
Subject: [CFRG] draft-fluhrer-lms-more-parm-sets
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, 11 May 2021 19:19:54 -0000

It looks to me like the requested changes happened in draft-fluhrer-lms-more-parm-sets-04 about a mont ago.  Is anything else needed to move this document forward?


> On Feb 19, 2021, at 2:36 AM, Stanislav V. Smyshlyaev <smyshsv@gmail.com <mailto:smyshsv@gmail.com>> wrote:
> Dear Scott,
> We are not waiting for any more reviews from the Crypto Review Panel. In my own opinion, there are no problems to confirm to IANA that CFRG is OK with the draft after updating the draft to reflect those minor issues .
> Regards,
> Stanislav
> On Sat, 13 Feb 2021 at 07:13, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com <mailto:sfluhrer@cisco.com>> wrote:
> Thank you for your review; I will be gathering together these editorial comments and updating the draft to reflect them.
> I do want to make a response to your "whiny suggeston" (not that I would classify it as whiny).  It is not generally true that a truncated SHA-512 would be faster than SHA-256 on a 64 bit processor (unless the message you're signing is long).
> Here's why: the SHA-512 hash compression function takes perhaps 50% more time than the SHA-256 hash compression function - however, it processes twice as much input, and so if you are hashing a long message, you end up processing it perhaps 30% faster.  That's fine for hashing long messages - LMS doesn't spend most of its time doing that.  Instead, a large majority of the hashes are done processing the LM-OTS winternitz chains, and the hashes there are carefully crafted to fit within 55 bytes (the most that SHA-256 can hash with a single hash compression call); replacing SHA-256 with SHA-512 would still have each step do a single hash compression call, but that hash compression call would take 50% longer.
> Of course, there are a number of other hash functions within the hierarchy; however the LM-OTS are the large majority (unless you happen to pick a tiny W), and so you'll end up spending more time.
> The only exception would be the initial message hash - if you are signing a sufficiently long message, then the bulk of the time would be spent during the initial message hash (where the superior bulk message performance of SHA-512 is relevent) - of course, if there were the case, another possibility would be to just hash the message with SHA-512, and then sign the hash using LMS with SHA-256.
> > -----Original Message-----
> > From: Jon Callas <jon@callas.org <mailto:jon@callas.org>>
> > Sent: Friday, February 12, 2021 9:04 PM
> > To: Stanislav V. Smyshlyaev <smyshsv@gmail.com <mailto:smyshsv@gmail.com>>
> > Cc: Jon Callas <jon@callas.org <mailto:jon@callas.org>>; crypto-panel@irtf.org <mailto:crypto-panel@irtf.org>; cfrg-chairs@ietf.org <mailto:cfrg-chairs@ietf.org>;
> > Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>; Scott Fluhrer (sfluhrer)
> > <sfluhrer@cisco.com <mailto:sfluhrer@cisco.com>>
> > Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-lms-
> > more-parm-sets?
> > 
> > 
> > 
> > > On Feb 9, 2021, at 9:41 AM, Stanislav V. Smyshlyaev <smyshsv@gmail.com <mailto:smyshsv@gmail.com>>
> > wrote:
> > >
> > > Dear Crypto Review Panel members,
> > >
> > > We would like to ask you to review additional parameter sets for LMS
> > defined in https://datatracker.ietf.org/doc/draft-fluhrer-lms-more-parm- <https://datatracker.ietf.org/doc/draft-fluhrer-lms-more-parm->
> > sets/
> > >
> > > We have already obtained support from Russ Housley (thanks a lot, Russ!);
> > could we ask for one more review?
> > >
> > 
> > Summary:
> > 
> > It's great, I approve. Two comments follow; one on consistency of
> > terminology that I believe is important and a one about algorithm choice that
> > I don't expect to be addressed, but I had to make.
> > 
> > Consistency in Editing:
> > 
> > In general, the draft uses "SHA256/192" for the truncated SHA256, and
> > "SHAKE256-xxx" for a SHAKE hash. That is to say, a slash is used with SHA and
> > a hyphen with SHAKE. Sometimes this is inconsistent and it caused me
> > consternation when my brain interpreted a slash to mean SHA and a hyphen
> > to mean SHAKE. Given that SHAKE starts with SHA and there's lots of 256s
> > being thrown around, it's really, really important to get this right, else
> > someone's going to make a mistake that will cause tears. I would even
> > support something too clever by half like using "SHA" to mean "SHA256/192"
> > for further aid to the mildly dyslexic like me. There are also places where
> > "SHA256" is written as "SHA-256." For example, Section 6 has all of these
> > inconsistencies. Please be consistent.
> > 
> > Whiny suggestion:
> > 
> > There's a construction for a variable-length output version SHA512 called
> > "SHA512/t" which is documented in <https://eprint.iacr.org/2010/548.pdf <https://eprint.iacr.org/2010/548.pdf>>.
> > One a 64-bit processor, SHA512 is faster than SHA256, often like 30-40%
> > faster. SHA512/t has changes to IVs to give different outputs. Section 3.1 of
> > this draft explains why IV changes aren't needed, so this draft could easily
> > have an option for a 192-bit truncation of SHA512. I know that at this date, it's
> > a big ask and arguably gilding the lily. It might even be a fine thing for another
> > document that throws that in, too. It might also be entirely too much to have
> > even more options. I was unable to pull my hands back from the keyboard,
> > though, because the whole point of this draft is for smaller, faster signatures
> > and the performance improvement of SHA512 leaps to mind. If you wanted
> > to add that in, I'd smile -- after all, the name of the draft is "more
> > parameters." I don't expect it.
> > 
> > All in all, a nicely done, elegant draft.
> > 
> >       Jon
> _______________________________________________
> Crypto-panel mailing list
> Crypto-panel@irtf.org <mailto:Crypto-panel@irtf.org>
> https://www.irtf.org/mailman/listinfo/crypto-panel