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

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Wed, 12 May 2021 16:27 UTC

Return-Path: <smyshsv@gmail.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 92D753A0E4C for <cfrg@ietfa.amsl.com>; Wed, 12 May 2021 09:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 eO5OLbyQy5At for <cfrg@ietfa.amsl.com>; Wed, 12 May 2021 09:27:23 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0F13A0EF1 for <cfrg@irtf.org>; Wed, 12 May 2021 09:27:23 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id f1so5575431edt.4 for <cfrg@irtf.org>; Wed, 12 May 2021 09:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wYJryk2BioSXfYAt9nBE7YMqTAyqrtcPZWRGvxB1A6w=; b=OSt1QhtnHdkqqm9W8PKXkaS5ntJebuhpdirdMR6jrempZVPiBDdPIyg8yAE0NzT+7v 2dOg2XsdlJq78X7xtkFfS/9lKPMKVAlzp/PYX+ORhhNSWNgxjghpeNZubayRvAPxbBvg B0s/uoGx/CYHUGzme3a/jcFk5cUcO9eGDFAYWIIHYhDtx6YwwuQU8QWsxaI8tZRf3rQQ gbBzJVOq3Nd9uyzfKWsxj4CteychDq4gBpiQTVPTlHEdO8G05t8L2K0yJOM+mwb3ZVDN uyJ2DXjH3EbR35UsGx4nCOudff6UuOJ85nx88IFdXsYUdHQ8DTXqITSo3snI7tim8gN2 xIFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wYJryk2BioSXfYAt9nBE7YMqTAyqrtcPZWRGvxB1A6w=; b=G4SS8dp76Kpw0ex9f3UfzZKemKlM3J8G6xPPm21NhyyhAv95PYARu4aejCogt6VRzb dUN2wpY1SqEvChamO1USDVGoE3spIZcaLR3Va/MCydYp4rpn8E+5ZE6kvoKQsFOGPozg UKTOxJsjSHnO8hRaNe7sLoCF9ejniuK2AAbcYFfp8jG6aenPUow3kcpT7TVUGua7THWa +HpupcO7XGCELs9h3PgreXgfGtzL6KxcoaHySAZ82ECWUDfTdA+JKZpKtcg2ojJUZen1 Pc4/DzSEM8Jaknz/fg7ZyvuQuP87dF5c4TSQjEmrs5oF+Yd53HYtZ7GH746Qrlt3SSzU vLpQ==
X-Gm-Message-State: AOAM532PhfYv5yK0yp+bWgxIleox3vpaF/8NPI0MGlYv3IR3SPxeWLNU kX9d5xi5kvjq6YfWD34BbGnCu54kJFAxChD4EGs=
X-Google-Smtp-Source: ABdhPJzqVHN0uAbZivtMOxWi5OWwZnG1n85r9WLL3zBNChogWrV+l7d4lSwP5RY2ZX7myVZERSc54M0STyd+/A8SLHE=
X-Received: by 2002:aa7:c7c5:: with SMTP id o5mr44124913eds.31.1620836839815; Wed, 12 May 2021 09:27:19 -0700 (PDT)
MIME-Version: 1.0
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> <2E3C2B18-22E1-4C10-99BE-CA09298F5472@vigilsec.com>
In-Reply-To: <2E3C2B18-22E1-4C10-99BE-CA09298F5472@vigilsec.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Wed, 12 May 2021 19:27:19 +0300
Message-ID: <CAMr0u6mMFuUqLixsOa7KftxZqBrU5M=Bfv1p0kkawRgSrFnoDw@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>, IRTF CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000137d3405c2247c3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/_WtSAWjmappEfbUqqbTWhmOWzyo>
Subject: Re: [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: Wed, 12 May 2021 16:27:29 -0000

Hi Russ,

The minor editorial issue with "SHA-256 vs SHA256" has been addressed, so
we have two positive reviews of the Crypto Review Panel members.

On behalf of CFRG chairs, we can state that the requirement
>> IANA MUST verify that all applications for additions to these registries
have first

   been reviewed by the IRTF Crypto Forum Research Group (CFRG)

is satisfied for draft-fluhrer-lms-more-parm-sets.


Regards,

Stanislav (on behalf of CFRG chairs)


On Tue, 11 May 2021 at 22:20, Russ Housley <housley@vigilsec.com> wrote:

> 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?
>
> Russ
>
>
> On Feb 19, 2021, at 2:36 AM, Stanislav V. Smyshlyaev <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>
> 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>
>> > Sent: Friday, February 12, 2021 9:04 PM
>> > To: Stanislav V. Smyshlyaev <smyshsv@gmail.com>
>> > Cc: Jon Callas <jon@callas.org>rg>; crypto-panel@irtf.org;
>> cfrg-chairs@ietf.org;
>> > Russ Housley <housley@vigilsec.com>om>; Scott Fluhrer (sfluhrer)
>> > <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>
>> > 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-
>> > 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
>> >.
>> > 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
> https://www.irtf.org/mailman/listinfo/crypto-panel
>
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>