Subject: [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 8 Feb 2021 14:39:18 +0000

Hi,

   Quynh Dang and I are trying to reserve IANA code points for the additional parameter sets within draft-fluhrer-lms-more-parm_sets.  The goal of these parameter sets is to reduce the signature size (by about a third on average) while maintaining a reasonably conservative security level (192 bits of security).

  One requirement for this to happen is found in the text of RFC 8554, which states (in section 8, IANA Considerations):

   Additions to these registries require that a specification be
   documented in an RFC or another permanent and readily available
   reference in sufficient detail that interoperability between
   independent implementations is possible [RFC8126].  IANA MUST verify
   that all applications for additions to these registries have first
   been reviewed by the IRTF Crypto Forum Research Group (CFRG).

   I am formally requesting such a review take place.

   Thank you

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 Feb 2021 10:10:52 -0500

I have reviewed the document, and I would like to see it move forward quickly.  SUIT could really use this.

Russ

> On Feb 8, 2021, at 9:39 AM, Scott Fluhrer (sfluhrer) <sfluhrer=[email-masked]> wrote:
> 
> Hi,
>

---

From: John Mattsson <[email-masked]>
Date: Wed, 10 Feb 2021 13:04:47 +0000

Hi,

I have reviewed the draft. Solutions to reduce signature size is welcome. The design choices make a lot of sense to me. I strongly support IANA registration of these parameters.

- I think the draft should have a reference to NIST SP 800-208, which already specifies these parameters. I think it is very useful to know that these parameters align with NIST SP 800-208.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf

- My understanding is that NIST SP 800-208 fulfills the requirements for IANA registration and this this draft is not strictly needed for IANA registration. Having the draft anyway is of course ok.

- "are efficient to compute"
I guess it depends of what you compare with. My understanding is that hash-based signatures are slower than lattice-based, multivariate, and ECC, but faster than RSA.
- I think the draft should mention how the 192-bit hashes affect the resistance to generic collision searches as described in NIST SP 800-208:
“Consequently, one trade-off for the use of 192-bit hash functions in LMS and XMSS is the weakening of the verifier’s assurance that the signer will not be able to change the message once the signature is revealed. This possibility does not affect the formal security properties of the schemes because it remains the case that only the signer could produce a valid signature on a message.”

- "take more time than is likely to be acceptable to any attacker"
Likely also acceptable by the user of the signatures. Given that quantum computers after error-correction currently are significantly slower that classical computers, the attacker would be dead a long time ago. It seems non-trivial to run a quantum computer for hundereds of years without interuption or to transfer its state.

- "SHA259/192"

- "SHAKE256" or "SHAKE-256"

- "SHAKE256-256" or "SHAKE256/256"

- "SHAKE256-192" or "SHAKE256/192"

John

From: CFRG <[email-masked]> on behalf of Russ Housley <[email-masked]>
Date: Monday, 8 February 2021 at 16:11
To: IRTF CFRG <[email-masked]>
Subject: Re: [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?

Russ

On Feb 8, 2021, at 9:39 AM, Scott Fluhrer (sfluhrer) <sfluhrer=[email-masked]<mailto:sfluhrer=[email-masked]>> wrote:

Hi,

   Thank you