
From nobody Tue Feb  9 09:42:00 2021
Return-Path: <smyshsv@gmail.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE8A3A1072 for <crypto-panel@ietfa.amsl.com>; Tue,  9 Feb 2021 09:41:59 -0800 (PST)
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 PsU6oXl4XoZE for <crypto-panel@ietfa.amsl.com>; Tue,  9 Feb 2021 09:41:57 -0800 (PST)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 55E8F3A1078 for <crypto-panel@irtf.org>; Tue,  9 Feb 2021 09:41:57 -0800 (PST)
Received: by mail-ej1-x62c.google.com with SMTP id lg21so33104857ejb.3 for <crypto-panel@irtf.org>; Tue, 09 Feb 2021 09:41:57 -0800 (PST)
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 :cc; bh=GK3MavLstTTx+cz/LgzqxoDZuroabEsIzROCoBDz/Z4=; b=RJJw99uOGKvekKAnp86WSEqA8Q617yzX55B0REfQdXqocM0ZjKN8xmfnz0ePMjV5C7 mWINoEEEkDJJufiLYSkNkpHPfP5WjCivxwVs3FfQLsZUVYWZPE6w5WmO0Yec90Aebk7O GXr1yUZzzpP2Xvn7GLMe/isvmTAw0SlJH8q+VgK9NYPAUDsD3sMnMY7KbbNor87VwvNh sTRsqLSwc9WCQaeAvi0uqs419mPGaoHvZaso9Mh+TQc9hyJWEvcYUUCFiB/7wH+Jb/qu 5WLtbCjheWttSxIeYlrBFzWtEDOtGQN0mBJOjsxUbcYkZEAe6qJwVrkNBkJhxI2aVzPS STFA==
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:cc; bh=GK3MavLstTTx+cz/LgzqxoDZuroabEsIzROCoBDz/Z4=; b=D5jp75+5uHx7+tGCSo8TrsEa4PTMElhOHUBYSPy1kl6DEstqKP6rs+nEH1j7EkMbgJ awdNvy57bEh7DOG5K0dqrEX3BbKHdlbD6jIPnSYCypUNcEN/oJKG2oWsQm0A1rtoWkpn mSEwPtfYgLijvU4xR3RaK4jhCyY06Qy8cI8E8XAkLmQGQMDRfICMN1xT4yhKC+8CO0Xx CH0V+rMbOqe+BmjVGvKHqhoEUBjBwuc9fems2uR0ANBNg9xtw8/p2XLe2GNa/BqAViub lOZhR2ksIraWl/BmqpKfDrcjdXGuf9oD9OCOB8yfLR0GPb1My9zSJXxgWJ55/zutNDrp FBXg==
X-Gm-Message-State: AOAM533r3W8NLIXtQXGKRMqdm1msNrx7BLjy5xiQXAsgBKs1MQzGscDK ji+sZs6+z0Ghq/4+j4lnXQOxy6sWfOLrL176DMt0XssCIdY=
X-Google-Smtp-Source: ABdhPJzv6LPPtE5adrWm4SbbgzdwePWEGcsa+zyje6rgkfXF/JPKtfMPSYhg8zxTQgEGFrOc4bgwAONqnfDPo5DQBJU=
X-Received: by 2002:a17:907:2805:: with SMTP id eb5mr23452438ejc.277.1612892515448;  Tue, 09 Feb 2021 09:41:55 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR11MB264152C19ECEFD79A61E7DDDC18F9@BN7PR11MB2641.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB264152C19ECEFD79A61E7DDDC18F9@BN7PR11MB2641.namprd11.prod.outlook.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Tue, 9 Feb 2021 20:41:49 +0300
Message-ID: <CAMr0u6nG-APMtEOn=xYdjBF0q3So6UEp-Nu0aB8tNEr154KNoA@mail.gmail.com>
To: crypto-panel@irtf.org
Cc: Scott Fluhrer <sfluhrer@cisco.com>, Russ Housley <housley@vigilsec.com>, cfrg-chairs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000071b93b05baeacd70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/Iig5n9IbuDz5XSuEI6YP-lcvGaE>
Subject: [Crypto-panel] Fwd: [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2021 17:41:59 -0000

--00000000000071b93b05baeacd70
Content-Type: text/plain; charset="UTF-8"

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?

Regards,
Stanislav, Nick, Alexey



---------- Forwarded message ---------
From: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco.com@dmarc.ietf.org>
Date: Mon, 8 Feb 2021 at 17:41
Subject: [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
To: cfrg@irtf.org <cfrg@irtf.org>


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
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--00000000000071b93b05baeacd70
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear Crypto Review Panel members,<div><br></div><div>We wo=
uld like to ask you to review additional parameter sets for LMS defined in=
=C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-fluhrer-lms-more-pa=
rm-sets/">https://datatracker.ietf.org/doc/draft-fluhrer-lms-more-parm-sets=
/</a></div><div><br></div><div>We have already obtained support from Russ H=
ousley (thanks a lot, Russ!); could we ask for one more review?</div><div><=
br></div><div>Regards,</div><div>Stanislav, Nick, Alexey</div><div><br></di=
v><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">---------- Forwarded message ---------<br>From: <strong class=3D"gmail=
_sendername" dir=3D"auto">Scott Fluhrer (sfluhrer)</strong> <span dir=3D"au=
to">&lt;sfluhrer=3D<a href=3D"mailto:40cisco.com@dmarc.ietf.org">40cisco.co=
m@dmarc.ietf.org</a>&gt;</span><br>Date: Mon, 8 Feb 2021 at 17:41<br>Subjec=
t: [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?<br>To: <=
a href=3D"mailto:cfrg@irtf.org">cfrg@irtf.org</a> &lt;<a href=3D"mailto:cfr=
g@irtf.org">cfrg@irtf.org</a>&gt;<br></div><br><br>





<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:break=
-word">
<div class=3D"m_-7384702918838611460WordSection1">
<p class=3D"MsoNormal">Hi,<u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">=C2=A0=C2=A0 Quynh Dang and I are trying to reserve =
IANA code points for the additional parameter sets within draft-fluhrer-lms=
-more-parm_sets.=C2=A0 The goal of these parameter sets is to reduce the si=
gnature size (by about a third on average) while
 maintaining a reasonably conservative security level (192 bits of security=
).<u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">=C2=A0 One requirement for this to happen is found i=
n the text of RFC 8554, which states (in section 8, IANA Considerations):<u=
></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
=C2=A0=C2=A0 Additions to these registries require that a specification be<=
u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
=C2=A0=C2=A0 documented in an RFC or another permanent and readily availabl=
e<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
=C2=A0=C2=A0 reference in sufficient detail that interoperability between<u=
></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
=C2=A0=C2=A0 independent implementations is possible [RFC8126].=C2=A0 IANA =
MUST verify<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
=C2=A0=C2=A0 that all applications for additions to these registries have f=
irst<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
=C2=A0=C2=A0 been reviewed by the IRTF Crypto Forum Research Group (CFRG).<=
u></u><u></u></span></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">=C2=A0 =C2=A0I am formally requesting such a review =
take place.<u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">=C2=A0=C2=A0 Thank you<u></u><u></u></p>
</div>
</div>

_______________________________________________<br>
CFRG mailing list<br>
<a href=3D"mailto:CFRG@irtf.org" target=3D"_blank">CFRG@irtf.org</a><br>
<a href=3D"https://www.irtf.org/mailman/listinfo/cfrg" rel=3D"noreferrer" t=
arget=3D"_blank">https://www.irtf.org/mailman/listinfo/cfrg</a><br>
</div></div></div>

--00000000000071b93b05baeacd70--


From nobody Tue Feb  9 12:06:06 2021
Return-Path: <jon@callas.org>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF73A11EB for <crypto-panel@ietfa.amsl.com>; Tue,  9 Feb 2021 12:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, 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=callas.org
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 IzToaBIApL5s for <crypto-panel@ietfa.amsl.com>; Tue,  9 Feb 2021 12:06:02 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 07BFE3A11E9 for <crypto-panel@irtf.org>; Tue,  9 Feb 2021 12:06:01 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id z7so486115plk.7 for <crypto-panel@irtf.org>; Tue, 09 Feb 2021 12:06:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pPGYa6d8DITNuuxIB5OtaHPXbWXEZRTsQNqJfh0Qr5Y=; b=QpOqzZSKbnpcW8zHWbSB7tt9LnDc9inL7ceS0Rv+2T/0ADYX1H9CnfEjQhCFJtl4Yg mgUrd6VcC2yndNxWt4u9ZZZz3ZF3MJ/hpVQGAnqklgmGRIlDL/plVO72YmcJOxe3Hh57 PywXkTWZXZ9HbA/3T1l1HDyAqZdZ5+Qklu8HmD6cJXUKOF0E18lFVVww0Jjpq4Va4AE4 A83OQY+ONxdunrMow7d8GjPnJZTMpS+n1aa84tAzhQC/Zq6UtefN6VU254c47+14J/9t YCnDOtTRQnQ9ZxOMBCbOadlGpGMU6z7xs3q2outY3s25P1LUDHrxjUAABSiFO7OhIsso IJmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pPGYa6d8DITNuuxIB5OtaHPXbWXEZRTsQNqJfh0Qr5Y=; b=HnYYGFWF1UONcNMHw9Ok9uDBdSBbVhX/ZnWjhh41r9IUsaMLekTIYFYKRsRpJN4g55 KijQq+PinpqR9YXaDYB5NWuqZ4/85CjOxbJ3hPGUTioAjK/sxv0uF+9Ge0TJHutsqeHX GWKxEJqliOEyKPAzHow0CwwXiAoYdUYPMZyJFo1/ilP7mPdEx+2duj3WHAWL0y7LV9z6 HbJgQjYiWvAIPeoypW1vcVURq+djEFOR5mZhp/M2DvvuL7or083J1InAgMzKCF8MXcr6 xOBC5mljjnej6Lh/ABES4LTHdFq5IzlYyDZ3vFJF7fsEZgIBrP2t2ylWfbKDO9tbv36j axbA==
X-Gm-Message-State: AOAM530CWqZehyq23Y1U48pByqINcK2Bi/Z1b2kv2keocQuHJXVBIqsR 6BPQDZbKphTDpFjzvyDv4hs6sA==
X-Google-Smtp-Source: ABdhPJznyLEApQV/IbM+2HvXDEUJMSdDwFHzSH84GP8O6Hwcbww3wulNwjHxf7dtRZXisz/mnB0D6g==
X-Received: by 2002:a17:902:7847:b029:df:d889:252c with SMTP id e7-20020a1709027847b02900dfd889252cmr22370164pln.76.1612901161581;  Tue, 09 Feb 2021 12:06:01 -0800 (PST)
Received: from ?IPv6:2600:1700:38c4:12bf:f583:f1e7:1481:e0ee? ([2600:1700:38c4:12bf:f583:f1e7:1481:e0ee]) by smtp.gmail.com with ESMTPSA id b15sm17307760pgj.84.2021.02.09.12.06.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Feb 2021 12:06:00 -0800 (PST)
From: Jon Callas <jon@callas.org>
Message-Id: <71C97FD8-0D03-43FD-AD81-BD9940D37C80@callas.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CFA79C55-9231-4717-ADE6-24505F325327"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Tue, 9 Feb 2021 12:05:59 -0800
In-Reply-To: <CAMr0u6nG-APMtEOn=xYdjBF0q3So6UEp-Nu0aB8tNEr154KNoA@mail.gmail.com>
Cc: Jon Callas <jon@callas.org>, crypto-panel@irtf.org, cfrg-chairs@ietf.org,  Russ Housley <housley@vigilsec.com>, Scott Fluhrer <sfluhrer@cisco.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
References: <BN7PR11MB264152C19ECEFD79A61E7DDDC18F9@BN7PR11MB2641.namprd11.prod.outlook.com> <CAMr0u6nG-APMtEOn=xYdjBF0q3So6UEp-Nu0aB8tNEr154KNoA@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/OP60zkKZaGMYDOD4O78oXydFftw>
Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2021 20:06:04 -0000

--Apple-Mail=_CFA79C55-9231-4717-ADE6-24505F325327
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Feb 9, 2021, at 9:41 AM, Stanislav V. Smyshlyaev =
<smyshsv@gmail.com> wrote:
>=20
> Dear Crypto Review Panel members,
>=20
> 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/ =
<https://datatracker.ietf.org/doc/draft-fluhrer-lms-more-parm-sets/>
>=20
> We have already obtained support from Russ Housley (thanks a lot, =
Russ!); could we ask for one more review?
>=20
> Regards,
> Stanislav, Nick, Alexey

Yes, I'll look at it. What schedule do you need it by?

	Jon



--Apple-Mail=_CFA79C55-9231-4717-ADE6-24505F325327
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Feb 9, 2021, at 9:41 AM, Stanislav V. Smyshlyaev &lt;<a =
href=3D"mailto:smyshsv@gmail.com" class=3D"">smyshsv@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">Dear Crypto Review Panel members,<div =
class=3D""><br class=3D""></div><div class=3D"">We would like to ask you =
to review additional parameter sets for LMS defined in&nbsp;<a =
href=3D"https://datatracker.ietf.org/doc/draft-fluhrer-lms-more-parm-sets/=
" =
class=3D"">https://datatracker.ietf.org/doc/draft-fluhrer-lms-more-parm-se=
ts/</a></div><div class=3D""><br class=3D""></div><div class=3D"">We =
have already obtained support from Russ Housley (thanks a lot, Russ!); =
could we ask for one more review?</div><div class=3D""><br =
class=3D""></div><div class=3D"">Regards,</div><div class=3D"">Stanislav, =
Nick, Alexey</div></div></div></blockquote><br class=3D""></div><div>Yes, =
I'll look at it. What schedule do you need it by?<div class=3D""><br =
class=3D""></div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>Jon<br class=3D""><div><br =
class=3D""><blockquote type=3D"cite" =
class=3D""></blockquote></div></div></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_CFA79C55-9231-4717-ADE6-24505F325327--


From nobody Tue Feb  9 21:48:35 2021
Return-Path: <smyshsv@gmail.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738EE3A13F1 for <crypto-panel@ietfa.amsl.com>; Tue,  9 Feb 2021 21:48:34 -0800 (PST)
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 Y2kI_9oppJcV for <crypto-panel@ietfa.amsl.com>; Tue,  9 Feb 2021 21:48:32 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 744613A13DA for <crypto-panel@irtf.org>; Tue,  9 Feb 2021 21:48:32 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id v7so1323639eds.10 for <crypto-panel@irtf.org>; Tue, 09 Feb 2021 21:48:32 -0800 (PST)
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 :cc; bh=6k+ZBDOiCpfDdYLU15b22lM4p/tF74dC6H9JKesCbM8=; b=XcRQ0Ex61EQc0P8Pnl5ZfKkhRs0aOCMFhlF7WA7fQqznCtzO53I4B4b58wzT42ytNi 9BMksuTdHF/8eJ9R3wQYNrjEed/CBMxOWkHd+biop0hWii1ycBlxr9bp8j3m25BdzCTi Ek10g5i/zC5Y7ZjQttsUPcVp87jBSewyZ5yi12uLFc0tbs5Jt312Q/ZEOT20brKUziSv B3+uClu2x9KRqiwSW+O/vmvjQF7wg+dM5VxX+UIVmJamfva/qFbLAlZeH3BNbY3PriLf eIhXmH4ouKFxAAN/+e6MA43DGassp+acenVyeU2Jgdenw10q1nwmCTW0fhCI128waWQB rhQw==
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:cc; bh=6k+ZBDOiCpfDdYLU15b22lM4p/tF74dC6H9JKesCbM8=; b=Wc8YqEeKeT5V3hOKKiHJUXvV/g50LnaZuB49xKk/HHjdTMnkPqytpKNrZYO89ODDtg GyKzRpCJq8r3dLnHeImCVEQlO4t6i0d4Sj7QqeYoz8NAK5hJtEt0yyfQqWAa3WZ15VDw 1lzvHDMAPKkefQrK0QVMGzOJaIlXpjbDyxK6BA4/qHtZoNvG34P0hmnYDAvv0y+uhulL q/mOJSzyCW/1XpFVQy3Cym5NHTWWYj+0wMO7emWduaYx+q7HlX2VS66/dSCzf6g80XDe YWPKGsnQw7yb7bZflb+QFBIuDokAF25ad2SUAI2pEfEIMB6JhkrVvwZniYHo9eoPqnxJ kr5w==
X-Gm-Message-State: AOAM5337ytYMhW0LIpoVW6k1BpMM9spJrdKt5lg99n4iAv4i3SKgeHYU Un02kcPu2ulvbMBml15UFd86IGoQ0kLAXND+80M=
X-Google-Smtp-Source: ABdhPJz44EFY0k7W4AAw5l9+BFR7YVSqXYpPUQrlvawldKnoSMLtEmZwxrpqttd5ddc2PD95t820CuxzPyLghBen9Ns=
X-Received: by 2002:aa7:c78e:: with SMTP id n14mr1559416eds.31.1612936110697;  Tue, 09 Feb 2021 21:48:30 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR11MB264152C19ECEFD79A61E7DDDC18F9@BN7PR11MB2641.namprd11.prod.outlook.com> <CAMr0u6nG-APMtEOn=xYdjBF0q3So6UEp-Nu0aB8tNEr154KNoA@mail.gmail.com> <71C97FD8-0D03-43FD-AD81-BD9940D37C80@callas.org>
In-Reply-To: <71C97FD8-0D03-43FD-AD81-BD9940D37C80@callas.org>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Wed, 10 Feb 2021 08:48:19 +0300
Message-ID: <CAMr0u6kzwX--pV9B3abbBDdQSuwELdjXON=gRWFjFjnzQV5KXA@mail.gmail.com>
To: Jon Callas <jon@callas.org>
Cc: Russ Housley <housley@vigilsec.com>, Scott Fluhrer <sfluhrer@cisco.com>, cfrg-chairs@ietf.org, crypto-panel@irtf.org
Content-Type: multipart/alternative; boundary="000000000000ec705305baf4f333"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/KqhpdQkQQ67yYKy1hkfE2MTcANY>
Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2021 05:48:34 -0000

--000000000000ec705305baf4f333
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks a lot, Jon!

Could you please do it in two weeks?

Kind regards,
Stanislav

=D0=92=D1=82, 9 =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3. =D0=B2 23:06, Jon Ca=
llas <jon@callas.org>:

> 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?
>
> Regards,
> Stanislav, Nick, Alexey
>
>
> Yes, I'll look at it. What schedule do you need it by?
>
> Jon
>
>
>

--000000000000ec705305baf4f333
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Thanks a lot, Jon!</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Could you please do it in two weeks?<br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Kind regards,</div><div dir=3D"auto">Stanisla=
v</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">=D0=92=D1=82, 9 =D1=84=D0=B5=D0=B2=D1=80. 2021=C2=A0=D0=B3. =D0=B2 23=
:06, Jon Callas &lt;<a href=3D"mailto:jon@callas.org">jon@callas.org</a>&gt=
;:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd;line-break:after-white-space"><div><div><blockquote type=3D"cite"><div>O=
n Feb 9, 2021, at 9:41 AM, Stanislav V. Smyshlyaev &lt;<a href=3D"mailto:sm=
yshsv@gmail.com" target=3D"_blank">smyshsv@gmail.com</a>&gt; wrote:</div><b=
r><div><div dir=3D"ltr">Dear Crypto Review Panel members,<div><br></div><di=
v>We would like to ask you to review additional parameter sets for LMS defi=
ned in=C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-fluhrer-lms-m=
ore-parm-sets/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-fl=
uhrer-lms-more-parm-sets/</a></div><div><br></div><div>We have already obta=
ined support from Russ Housley (thanks a lot, Russ!); could we ask for one =
more review?</div><div><br></div><div>Regards,</div><div>Stanislav, Nick, A=
lexey</div></div></div></blockquote><br></div><div>Yes, I&#39;ll look at it=
. What schedule do you need it by?</div></div></div><div style=3D"word-wrap=
:break-word;line-break:after-white-space"><div><div><div><br></div><div><sp=
an style=3D"white-space:pre-wrap">	</span>Jon<br><div><br><blockquote type=
=3D"cite"></blockquote></div></div></div><br></div></div></blockquote></div=
></div>

--000000000000ec705305baf4f333--


From nobody Fri Feb 12 18:04:29 2021
Return-Path: <jon@callas.org>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7044B3A11EA for <crypto-panel@ietfa.amsl.com>; Fri, 12 Feb 2021 18:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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=callas.org
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 Oi62Sf5ctiQi for <crypto-panel@ietfa.amsl.com>; Fri, 12 Feb 2021 18:04:25 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 B25F23A11E9 for <crypto-panel@irtf.org>; Fri, 12 Feb 2021 18:04:25 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id x9so767342plb.5 for <crypto-panel@irtf.org>; Fri, 12 Feb 2021 18:04:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I9s/VEf0cvL6qy6ZAGndY68d0uJ0cDQ4xRSCvBHEPMQ=; b=ZCiIhZnQsopqsc7Cm1ob/JZoEQavFZ7NAtR4/89XtZEognFTZn+gYP6z5S62tD/zzk f4DASaCOtWYRID0r4A+JRrN2PMibYdS/AiFZhYef8cTCJcAh9DKYVGsxfsLdlpPMrG2a I50cFlvkANwmpqNJaVKARFjdai+JWwFUOCC8lhLuSzTLHZcnv/bvFxQhe+blyCFJ51r0 A8WchBUqc+FpjPGSTh6XG1Zaeho5GmjS0JnLsx+VAFhAXB7WenE0Y2tCTdRZS0KOhd/q pAutFSLmsXeNnzCQ48jyKaW+xnxInlkYrjuck14HR8dgV7b3VwxYdMGatcxb+nv6dp3x U7gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I9s/VEf0cvL6qy6ZAGndY68d0uJ0cDQ4xRSCvBHEPMQ=; b=tppvfrC4M6+3u68sumx+MMaEfF5hzjKaaYzjS2Q952lciUwLqSvcBUOt6282QZviwQ kfFD4i7kpb2pXS2/IGC292E2WGaWA9PPnOsSGDeaPiXwIJ15m/SUCQDnzYlieKpM2Y2o zhBJbzYIi9r45BodTctUKRP8PZebeMDFRfs65J3ZKq6Ei/xm9FPchwqNXuGUPxVsIQsG ewt2W+4TlTsH9yjtRie5tt4759AUoxMNlXPCro+q7xGUIzGF7BJ/9F5OMStbjZWiTXvI kVvjb6se9/5UiO9bB24EOtpg/DVePSB4UGgkLEYkafvZ8joEG5hg35FYeMK5kudaaA8m n5SQ==
X-Gm-Message-State: AOAM532nKHgG5+uaiP9UQ5OQ9xgpykw0pxTNdKEYWGA64+IuOkqv3rUa s/I4MSTCOy+GwLc4wFNB8kYHVg==
X-Google-Smtp-Source: ABdhPJzVBMlZzgWYhTFqpbALSKkYqrPrrFYFvxt4EMfoGpIGKCqOJIw0FjAsrl0wJLceEaZlqVosXw==
X-Received: by 2002:a17:902:d48e:b029:e2:efbc:5fed with SMTP id c14-20020a170902d48eb02900e2efbc5fedmr5329533plg.53.1613181863915;  Fri, 12 Feb 2021 18:04:23 -0800 (PST)
Received: from ?IPv6:2600:1700:38c4:12bf:3592:2265:db32:cb0? ([2600:1700:38c4:12bf:3592:2265:db32:cb0]) by smtp.gmail.com with ESMTPSA id c24sm10042728pfo.209.2021.02.12.18.04.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Feb 2021 18:04:23 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <CAMr0u6nG-APMtEOn=xYdjBF0q3So6UEp-Nu0aB8tNEr154KNoA@mail.gmail.com>
Date: Fri, 12 Feb 2021 18:04:21 -0800
Cc: Jon Callas <jon@callas.org>, crypto-panel@irtf.org, cfrg-chairs@ietf.org,  Russ Housley <housley@vigilsec.com>, Scott Fluhrer <sfluhrer@cisco.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA7EDC73-C399-4089-B89A-0B6EF89EDC21@callas.org>
References: <BN7PR11MB264152C19ECEFD79A61E7DDDC18F9@BN7PR11MB2641.namprd11.prod.outlook.com> <CAMr0u6nG-APMtEOn=xYdjBF0q3So6UEp-Nu0aB8tNEr154KNoA@mail.gmail.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/zBjyGDLz3Gzo2u09hjOlzcZlbqI>
Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2021 02:04:27 -0000

> On Feb 9, 2021, at 9:41 AM, Stanislav V. Smyshlyaev =
<smyshsv@gmail.com> wrote:
>=20
> Dear Crypto Review Panel members,
>=20
> 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/
>=20
> We have already obtained support from Russ Housley (thanks a lot, =
Russ!); could we ask for one more review?
>=20

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


From nobody Fri Feb 12 20:13:19 2021
Return-Path: <sfluhrer@cisco.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76273A0C87 for <crypto-panel@ietfa.amsl.com>; Fri, 12 Feb 2021 20:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level: 
X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hBDV8Vwb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PpOaO+IZ
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 y5zUbL-kNfXO for <crypto-panel@ietfa.amsl.com>; Fri, 12 Feb 2021 20:13:14 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFF43A0C98 for <crypto-panel@irtf.org>; Fri, 12 Feb 2021 20:13:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4813; q=dns/txt; s=iport; t=1613189594; x=1614399194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qw+y8ZPkOlqsNgROyetCi54BL3HakukUcBfzbgSq1Uw=; b=hBDV8Vwboxxa0yVktSkd6dn6iAZ6rj7vxcayfJWaNpi3urh1SyN6pDWm XIQNNDywtCh/6KRhklqAAZG/Ig77CvvDBpwCt9FojQ+SccgbrJDI/pQHc 8jxWy+0QWnEEvU3sm7H3034kR4vy95e7bCgnN/n/QYT68jqwIZDvlYWAv s=;
X-IPAS-Result: =?us-ascii?q?A0CjAAAcUSdgmIkNJK1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4FTUX1aNjEKAYd+A44HA4ofjn2BQoERA1QLAQEBDQEBKAoCBAEBh?= =?us-ascii?q?EwCggcCJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGNg2GRAEBA?= =?us-ascii?q?QICOgYBATcBCwQCAQgRBAEBAR4QIREdCAEBBAENBQiCaAGCVQMuAQ6lNwKKJ?= =?us-ascii?q?XSBNIMEAQEGgTMBE0GDEw0LghIDBoE4gnaFEoQbgR8mHIFBQYERQ4IoLj6CG?= =?us-ascii?q?0ICAQEBAYEhPINIgiuBWGxqBC8kgQUTeiqba5xSCTBbCoJ6iTeNKoVLgzGKR?= =?us-ascii?q?5U0lDiLLIMBjniEVQICAgIEBQIOAQEGgWwhgVlwFYMkUBcCDY4fCQIBDgkUg?= =?us-ascii?q?zqFFIVFcwI1AgYKAQEDCXyKCAExXQEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3AkRUFyB8N4Qr6LP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN7vxpiFbSG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKwOExREd24YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,175,1610409600"; d="scan'208";a="669707087"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Feb 2021 04:13:13 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 11D4DDdY004397 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 13 Feb 2021 04:13:13 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Feb 2021 22:13:12 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 12 Feb 2021 22:13:12 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 12 Feb 2021 22:13:12 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RaPU5Giclc1+xSh7SnyI1Pu7YQHPJ0+BCgpomVJV5z4QLchBjTNQHgQde3jRR/Tnfm5ts+C72ig+/wquwLaH2BDys463mMKjtaVYDHAfL2sLcLq0ncpH8pGJVvNMdPDoMOYDLAojZYSAr+r6eojVWLjRY5s2on4bBm8DRDFoIEiKiACl8BwlTjhqNjEcOFi9I6yTOLBpI2al2GW5Aq7OPmXHwe0Xe94MH7nmnZhUAbUMQx8k/4k7rT53+vnBOtV9RU/WojUImEHspG1FjGAXbW8wV6EUnHcA0UYy2fvnBe5+9gW4x39DsQW3tCWFvB3ZCSsxdJJ28ePnKrWFkxRy6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hiKwRPzCysPOioSngU1dUC3rd8KhoP1QENpD56M2Dns=; b=neryVni9ssPECQSWY368qH6Uv+bZ45fJvNo7uvR2e0cS5ISMVGXPps/1rg8jl1fJ5Hx42lO0S+Hjhn6Wx0LDABj+ZMrwf54DIGI4Bp4S3ygGhUvmOAW34vdRtqsrgnOKG155k/8b2LAs+mzaU0vRzwxG+AFAfHrOzcIU+iDhC7HR7ZHZZ/DXGThcamowZm1MvNoOM4OBpczGuZRqwt+c1Q3WphWRRhI2jyK5QKI6Q9G7y3Bl++5YHu2pvPiOsP/5b5Z8bQH7Y0NDTaL2vBOEJR0gqNQ7ktD01W6W5b+Fxj6H2a/20ptDGy8qnsDW+ctGmp37omloY+9ql618F5eAvg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hiKwRPzCysPOioSngU1dUC3rd8KhoP1QENpD56M2Dns=; b=PpOaO+IZRAwzcCiL0qBq8ko8R4RO1vJM7LBOz+/ddn4Tuw3Udy5C0Sr5/hGrU1ZxbQhwslWpziw3/r5VE9syXx4NX42mDWhn7/E16swNxJ15SNPdiX85xO4hmeKC21bi2joHJ3ENU9IBDCd5SHA7mq7BvuwuLcQJHRa5OG5aXNw=
Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB1426.namprd11.prod.outlook.com (2603:10b6:405:b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.29; Sat, 13 Feb 2021 04:13:11 +0000
Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::4543:b45a:9f32:bde0]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::4543:b45a:9f32:bde0%7]) with mapi id 15.20.3846.026; Sat, 13 Feb 2021 04:13:10 +0000
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Jon Callas <jon@callas.org>, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
CC: "crypto-panel@irtf.org" <crypto-panel@irtf.org>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>, Russ Housley <housley@vigilsec.com>
Thread-Topic: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
Thread-Index: Adb+Jt9TjiOuqW6cRRiwxSMfcjtiJAA4/iGAAKhsz4AAA/Uw8A==
Date: Sat, 13 Feb 2021 04:13:10 +0000
Message-ID: <BN7PR11MB2641B951100EB5C8AD3023A2C18A9@BN7PR11MB2641.namprd11.prod.outlook.com>
References: <BN7PR11MB264152C19ECEFD79A61E7DDDC18F9@BN7PR11MB2641.namprd11.prod.outlook.com> <CAMr0u6nG-APMtEOn=xYdjBF0q3So6UEp-Nu0aB8tNEr154KNoA@mail.gmail.com> <EA7EDC73-C399-4089-B89A-0B6EF89EDC21@callas.org>
In-Reply-To: <EA7EDC73-C399-4089-B89A-0B6EF89EDC21@callas.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: callas.org; dkim=none (message not signed) header.d=none;callas.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dc249918-75b1-4dec-2a43-08d8cfd5ace5
x-ms-traffictypediagnostic: BN6PR11MB1426:
x-microsoft-antispam-prvs: <BN6PR11MB1426916DA7E537D3B2419628C18A9@BN6PR11MB1426.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rgWGGTC9AObPRbf0qmU8D5yVaQhskoy3+f534+rIwMzXnbLQ1haSPX5D6TBjA2TYxqMLPUTEW/D4HUEed6l0v2uptfJeBvzMJg1zq87um7CHtNzloVA/HRuzG4o3cXubYxT7cTIWoQJ1K22820arz7Bw+WWcOS4yNkMTF2nJEXCKEC198tVjbYnmXQjjqOfKZ+4PCzXB0/mOJBTLNiRo2Z1Dh5jXPFrPc7MhLuMFa5bXd0aulxjDS3rWPsRKcgDD8pB2sNc5u6YaBqcYGiRic0VpLFgRcU7Zs/UVNcWURZcYGWYBNoRQquz2wxGMsY+xsHpfcSkDMnvVQ2Tzzz4o3qKEZdKTqzhdo+lPjKlbyYS4XSAx3Ur3boTQWKlQFpJxbVUj/wIAObw+FrFxFzlx+cGMaHBY5Ew6iGHrt2PQiy4laFOz3oEvtMKZTeIFAFg3r24t7qrys3JRATb37jwKfs7wij9OkUR2QsTF9KXkY9/c75H2fSlPud2aFQM4PVg79lto/d77PbLG4ioma7gE7nB7Y9jR6dOD1HP4vD93z+/Wc/hlaAQheWZuUQK8bvZDNd2h+as1vqkSRnjoa2zzGSU1evEa3cSboyxVtrBwNZW98oe/LnMUh3FSfqAa73GARlabYTxLYp4JRS2t591PnQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFS:(346002)(39860400002)(376002)(136003)(366004)(396003)(6506007)(53546011)(66476007)(5660300002)(8936002)(316002)(8676002)(52536014)(86362001)(26005)(83380400001)(7696005)(2906002)(54906003)(186003)(110136005)(966005)(4326008)(71200400001)(478600001)(33656002)(9686003)(76116006)(55016002)(66946007)(66446008)(66556008)(64756008)(21314003); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?1n2xr8hKq35NghL5FrzNRdVrQP6ID7Fhfp2sBkXOV5xu7Y3Kkk18vJHxYK2J?= =?us-ascii?Q?8zBHOW3wFiWiGLFdI+VZtvmkMZsWG9eTFFdxiICikGPoAPTG0m8DHWGpmAfR?= =?us-ascii?Q?lp7oqgEK5AUzngTYgZ1Iyt1Ri0BrQG4u8HcnQ6f60QzdI8znDuZz8sViL+XU?= =?us-ascii?Q?1tpJVzjawW9dY5r2OACcJgkL0hqIzund+qaLDQcVyj/GT1nKXRYA6GCRaHqE?= =?us-ascii?Q?ZXY0rrWwzwxj/7fNpntdevSkb4nxhfc8i94qpR5Jg3h03j/qagyH2pqGaCyt?= =?us-ascii?Q?IdLRiJxw2GJV6BKXCtgjb+i+UrL3WRhnwV9Y57Mt8MH9c/Z6tW0Dn8C1AcUZ?= =?us-ascii?Q?j9HuT6NZ6s70e4U+b3ZOvMBOkblXeFkYJXUqM17mYwy0tNIlUcM3jDQtkaOz?= =?us-ascii?Q?P9mAzcVqb/rt+tprp8EMgYwzLABSbW3On0M6OMOFeqCcuzNAZsDlJCBDmAEp?= =?us-ascii?Q?4qGUOtKNuJBxFLGjcB8VLdqdNi6h8WwNY+AcDrR8wXF0AVkMjGj6wTF4bBpe?= =?us-ascii?Q?jdLJmxRWXv8Jv4rvXxMRKbXPbv8QYWzkPcdPDZKY64kTw0c7c2ahKlkT8WQ+?= =?us-ascii?Q?BM2G1CDObx7xZyxQm2RCL93jMAMvaOS/YtONUOSM/ebHWK8P2jZ5uvVMR1PP?= =?us-ascii?Q?ds/CJZQpc8txNHg0LNiLuniT42ceOsIO7DpS3n/gsbRLhCY+HdrU8IICMZoq?= =?us-ascii?Q?UfK2NVL/m61q+fLXf6Kf81dK16uEcGySg/ZJSyjs+6LAJxFNd9dxzUyXJz5e?= =?us-ascii?Q?J7xd+T9KKX87uajnCcJyA08gJnZoxgbU2kNgsmATqNw49YLflIftS514WHwD?= =?us-ascii?Q?XrAtVoiEx3LhkVU3AJtQnBPX1SuBjr2Sq2aIxau+esw5WcOoZDWitdqhqF+2?= =?us-ascii?Q?WtrSzCc+EqXF4DCny0QTqXItBfQhoqQSo2kOaw8mU5+FQ2iZDqPGgDqX+L3Q?= =?us-ascii?Q?e/G2sGBGnBkPJUu71pY0PqwZBFXxugxmzSKQRWYVEDIhAKrrDa4SlSZjpIA8?= =?us-ascii?Q?UDjIJvpeAr6JlmlIuTic4RzpOyvBspibhHM+36kvu+w6kIePhvmf0TwImuyG?= =?us-ascii?Q?/UaYmoB8RYvyQ7GMdBqzMSAuo9hULGMu11HjPtDHhghf+83E0EarELMX0QlX?= =?us-ascii?Q?DL0MMHK3cjenmvWKvZD3+GdkLmjIP4QtVQmRF6jyFVvq2CUZzSpsXYCvtyQB?= =?us-ascii?Q?z9aeFaQtRpUsH9cNmAC1QxhjDSPTCeKmN39tsObWFLbCjpPGD+G0MeZQW02i?= =?us-ascii?Q?nVqKOdM4IQQnwEzWWSpVuM/UZeUBQGlxKlzExm4NEnlSRz6lhQAGb9I+Cnp+?= =?us-ascii?Q?Ji14KKIRa0hj91yBeZirlLE5?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2641.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc249918-75b1-4dec-2a43-08d8cfd5ace5
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2021 04:13:10.7809 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xuZTbXH/ok9adPubxrLnCWW8jDqMIN4nrPvuGjtfMPU9AVQGSlzZq1x028iE2HRZgMw4ATHsfMcFVab8bIIKcw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1426
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/6m0EcLvMr77Vcn83xO761fcgC8s>
Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2021 04:13:18 -0000

Thank you for your review; I will be gathering together these editorial com=
ments and updating the draft to reflect them.

I do want to make a response to your "whiny suggeston" (not that I would cl=
assify it as whiny).  It is not generally true that a truncated SHA-512 wou=
ld 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 ti=
me 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 proces=
sing it perhaps 30% faster.  That's fine for hashing long messages - LMS do=
esn'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 the=
re 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 w=
ould 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 tin=
y 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 S=
HA-512 is relevent) - of course, if there were the case, another possibilit=
y would be to just hash the message with SHA-512, and then sign the hash us=
ing 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>; crypto-panel@irtf.org; cfrg-chairs@ietf.=
org;
> Russ Housley <housley@vigilsec.com>; Scott Fluhrer (sfluhrer)
> <sfluhrer@cisco.com>
> Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-l=
ms-
> more-parm-sets?
>=20
>=20
>=20
> > 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?
> >
>=20
> Summary:
>=20
> 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.
>=20
> Consistency in Editing:
>=20
> 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, els=
e
> 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 whe=
re
> "SHA256" is written as "SHA-256." For example, Section 6 has all of these
> inconsistencies. Please be consistent.
>=20
> Whiny suggestion:
>=20
> 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 eas=
ily
> have an option for a 192-bit truncation of SHA512. I know that at this da=
te, it's
> a big ask and arguably gilding the lily. It might even be a fine thing fo=
r 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 sign=
atures
> 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.
>=20
> All in all, a nicely done, elegant draft.
>=20
> 	Jon


From nobody Sat Feb 13 13:24:27 2021
Return-Path: <jon@callas.org>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82D13A0EED for <crypto-panel@ietfa.amsl.com>; Sat, 13 Feb 2021 13:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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=callas.org
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 m9i3JIa7FYyg for <crypto-panel@ietfa.amsl.com>; Sat, 13 Feb 2021 13:24:24 -0800 (PST)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 54F503A0EEA for <crypto-panel@irtf.org>; Sat, 13 Feb 2021 13:24:24 -0800 (PST)
Received: by mail-pg1-x533.google.com with SMTP id o38so1936069pgm.9 for <crypto-panel@irtf.org>; Sat, 13 Feb 2021 13:24:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E9m744NBQvUOxNir/qBAm8eB+E8qOx8DFBcSyf5tpG4=; b=Ri6zca/+xBT28adFlgF2uyKXya/iXn2z8F7xidEIFEQ3/1daWPBjwu6Aict9Ew5l6x St1s+6Kn2UXNa51Yq7faOep9rMdddB2AT9ere+fweGcVVSfvYlX8UjeL3vnUQ6PZb13P 2xAYk+E4aGQ/fj46rG2gGvfxuagCiY+CqgefduPy73mm/PlOymGDA/a8IOSlUGyE+Xm2 pcPr6QpN5z9bVU1XQdGDHRKEyzU+z33VwT9aE5qceF+qYL2C3tUjVhZcFc/MqpgD8e9J mR0jdRI2K2/KKTNlmn5Vp25vtBBRYHevPh4HcqtWaeo6Q501lvbgw6nhbEbym1eF+RnJ a1/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E9m744NBQvUOxNir/qBAm8eB+E8qOx8DFBcSyf5tpG4=; b=epN4pvvNvK01Kz5y2LF6CBPWsFD02/BOH+KRTgs64Xe9Sg8pNy3wHiTqV1xWh5ywR8 46xXZlQew/EfvYHL1zK0V3dWJzJvVAtOkKqgLYcUO0MeVM8HjcxHBf1UFzZLIHRTby91 cGBUPA6aY+5wxeqI2QBm/Q/K8H5zR8NXeva1xS4jkv/uAuLvoQ2zEZXZGL+YDhOX1orE CVMkoBdzB/RcbPzcAcG9j4qUc6MjsNrfufYcjhPgqYaaS9LBrLpqDDkQa4YTtOhaDjnF SpLcN5JnB+U1oKRG7Herzz1wwtztHwiGD5lyN0FQraYiaNfPwcyJx4ndxq0KCvD/hT4X 2pFA==
X-Gm-Message-State: AOAM53140++lVlZZkpK5Mnun3SnoIMoixGmhixcmy5VDBZn92YmB+5WI ovHzW2n3T0P+I6Tn9kdVNBI5GA==
X-Google-Smtp-Source: ABdhPJzRZNq6B1G4szYHhWOeCWeZNe3vM3GJB/xTKz3Ilha4THc6PNdhiKbWYOG6ke3e78a4odYIKA==
X-Received: by 2002:a63:748:: with SMTP id 69mr8619692pgh.112.1613251463610; Sat, 13 Feb 2021 13:24:23 -0800 (PST)
Received: from ?IPv6:2600:1700:38c4:12bf:3592:2265:db32:cb0? ([2600:1700:38c4:12bf:3592:2265:db32:cb0]) by smtp.gmail.com with ESMTPSA id 74sm13325492pfw.53.2021.02.13.13.24.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Feb 2021 13:24:23 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <BN7PR11MB2641B951100EB5C8AD3023A2C18A9@BN7PR11MB2641.namprd11.prod.outlook.com>
Date: Sat, 13 Feb 2021 13:24:22 -0800
Cc: Jon Callas <jon@callas.org>, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, "crypto-panel@irtf.org" <crypto-panel@irtf.org>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>, Russ Housley <housley@vigilsec.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EEABA8D1-86D1-47AA-99B9-3E6B73183381@callas.org>
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>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/6Z8ZmQjUO5y4kagCtneep2oIBvI>
Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2021 21:24:26 -0000

> On Feb 12, 2021, at 8:13 PM, Scott Fluhrer (sfluhrer) =
<sfluhrer@cisco.com> wrote:
>=20
> 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.
>=20

Thanks for the explanation, that was where my suspicions went -- first =
block overhead.

	Jon=


From nobody Thu Feb 18 23:36:54 2021
Return-Path: <smyshsv@gmail.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D373A11A9 for <crypto-panel@ietfa.amsl.com>; Thu, 18 Feb 2021 23:36:53 -0800 (PST)
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 IytBM7IE6Uai for <crypto-panel@ietfa.amsl.com>; Thu, 18 Feb 2021 23:36:50 -0800 (PST)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 362063A11A8 for <crypto-panel@irtf.org>; Thu, 18 Feb 2021 23:36:50 -0800 (PST)
Received: by mail-ej1-x629.google.com with SMTP id lu16so10635396ejb.9 for <crypto-panel@irtf.org>; Thu, 18 Feb 2021 23:36:50 -0800 (PST)
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 :cc; bh=GFS6GAqZEfy0qkQbK3/OLonDkZepLXpK3D5/g79PcaA=; b=tGX6JnlrLZpFVUm/BfW3DnRFKyjsAciRH7OXWu/zFfBVbr2XyBkA+pFbgcPuVp/oWI Jc8jvjEG2cbGzfdFXjs1+s6TDbMNe73jhB/dmyXq8zNhYY6iASEf4nYiUTiob1jDLWzU btfZR3w0KK5PA7/2opnEhniFFBB3Iwx5aG/GfgD6Z5LSbDKuRA2W+nOICk3sMFPvADxq 1BZ7w1VJPtBuCpiACG2KJxEb/iIi3uezflMMy4kHhGg5Ws2lGiBFYTZzK6q/ZZxvi917 FStncBldD7NrL0tC+JffpHsF5PIGdy2RK8lzmGdNYjUukozcrOPe7bB0I2B/G3TGPbR8 QFgA==
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:cc; bh=GFS6GAqZEfy0qkQbK3/OLonDkZepLXpK3D5/g79PcaA=; b=IsNw0X0H98NicMKrFSPwZEBrX7WbXItYjvAAATiXMTfDn117IR8SLrQiv2J5JLcVQv E+tFriN+e9PNAHK9LbBAAag+kvileNtBKBbHtm64Pk2//02qVxboK5bGhUk3xNVOi71O 4CfYk1L/+wVqI2ev0ZU7MGsW/VILd24szOXLp6v1IRNXCWKIcFHy4SDzGhZYNbKdXUS2 loSOLXiDwAoYy0BLRHf3erD1NN7rJ9n6KCWMXsSg51fK1n2TqK5BW9QmiaBT3uaJj7YS Nkheb4rECdAswdo6vnd4I+tQKQz8ycbALyZ5v4Dfgq8niLUB8lWaqWySU+pnmBmtddKS kk1g==
X-Gm-Message-State: AOAM530qBaietsV8w2l+wcPEuVXDJ2BlS/AEMHsjW9zjdeqbo7WuMit9 4opecJpUItt0+TC9rNjaKiYThS38veJbgR/bitE=
X-Google-Smtp-Source: ABdhPJyN5dJVRe+QPwgFgZHD22x/mr2jAL7Y1Zl8s8wcnvVDU+fFfK8e8Es1LFgRl1JcQa1NlX5KwDXuMFSu+htf3hY=
X-Received: by 2002:a17:907:3f13:: with SMTP id hq19mr7708752ejc.142.1613720208743;  Thu, 18 Feb 2021 23:36:48 -0800 (PST)
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>
In-Reply-To: <BN7PR11MB2641B951100EB5C8AD3023A2C18A9@BN7PR11MB2641.namprd11.prod.outlook.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Fri, 19 Feb 2021 10:36:32 +0300
Message-ID: <CAMr0u6m_w_g5tofgW6=Yo1im13TW+9F2uBAX90zsp+ycjWCy5g@mail.gmail.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Cc: Jon Callas <jon@callas.org>, "crypto-panel@irtf.org" <crypto-panel@irtf.org>,  "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>, Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="000000000000cf215405bbab83f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/M55FaYlUGI9b4p8f8Lj0UtkUrf0>
Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhrer-lms-more-parm-sets?
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2021 07:36:53 -0000

--000000000000cf215405bbab83f7
Content-Type: text/plain; charset="UTF-8"

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>; crypto-panel@irtf.org;
> cfrg-chairs@ietf.org;
> > Russ Housley <housley@vigilsec.com>; 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
>
>

--000000000000cf215405bbab83f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear Scott,<div><br></div><div>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=20

after updating the draft to reflect those minor issues=20

.</div><div><br></div><div>Regards,</div><div>Stanislav</div></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 13 Feb=
 2021 at 07:13, Scott Fluhrer (sfluhrer) &lt;<a href=3D"mailto:sfluhrer@cis=
co.com">sfluhrer@cisco.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">Thank you for your review; I will be gathering to=
gether these editorial comments and updating the draft to reflect them.<br>
<br>
I do want to make a response to your &quot;whiny suggeston&quot; (not that =
I would classify it as whiny).=C2=A0 It is not generally true that a trunca=
ted SHA-512 would be faster than SHA-256 on a 64 bit processor (unless the =
message you&#39;re signing is long).<br>
<br>
Here&#39;s why: the SHA-512 hash compression function takes perhaps 50% mor=
e time than the SHA-256 hash compression function - however, it processes t=
wice as much input, and so if you are hashing a long message, you end up pr=
ocessing it perhaps 30% faster.=C2=A0 That&#39;s fine for hashing long mess=
ages - LMS doesn&#39;t spend most of its time doing that.=C2=A0 Instead, a =
large majority of the hashes are done processing the LM-OTS winternitz chai=
ns, 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 compressio=
n call, but that hash compression call would take 50% longer.<br>
<br>
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 tin=
y W), and so you&#39;ll end up spending more time.<br>
<br>
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 S=
HA-512 is relevent) - of course, if there were the case, another possibilit=
y would be to just hash the message with SHA-512, and then sign the hash us=
ing LMS with SHA-256.<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: Jon Callas &lt;<a href=3D"mailto:jon@callas.org" target=3D"_blan=
k">jon@callas.org</a>&gt;<br>
&gt; Sent: Friday, February 12, 2021 9:04 PM<br>
&gt; To: Stanislav V. Smyshlyaev &lt;<a href=3D"mailto:smyshsv@gmail.com" t=
arget=3D"_blank">smyshsv@gmail.com</a>&gt;<br>
&gt; Cc: Jon Callas &lt;<a href=3D"mailto:jon@callas.org" target=3D"_blank"=
>jon@callas.org</a>&gt;; <a href=3D"mailto:crypto-panel@irtf.org" target=3D=
"_blank">crypto-panel@irtf.org</a>; <a href=3D"mailto:cfrg-chairs@ietf.org"=
 target=3D"_blank">cfrg-chairs@ietf.org</a>;<br>
&gt; Russ Housley &lt;<a href=3D"mailto:housley@vigilsec.com" target=3D"_bl=
ank">housley@vigilsec.com</a>&gt;; Scott Fluhrer (sfluhrer)<br>
&gt; &lt;<a href=3D"mailto:sfluhrer@cisco.com" target=3D"_blank">sfluhrer@c=
isco.com</a>&gt;<br>
&gt; Subject: Re: [Crypto-panel] [CFRG] Can I have a review of draft-fluhre=
r-lms-<br>
&gt; more-parm-sets?<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; &gt; On Feb 9, 2021, at 9:41 AM, Stanislav V. Smyshlyaev &lt;<a href=
=3D"mailto:smyshsv@gmail.com" target=3D"_blank">smyshsv@gmail.com</a>&gt;<b=
r>
&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; Dear Crypto Review Panel members,<br>
&gt; &gt;<br>
&gt; &gt; We would like to ask you to review additional parameter sets for =
LMS<br>
&gt; defined in <a href=3D"https://datatracker.ietf.org/doc/draft-fluhrer-l=
ms-more-parm-" rel=3D"noreferrer" target=3D"_blank">https://datatracker.iet=
f.org/doc/draft-fluhrer-lms-more-parm-</a><br>
&gt; sets/<br>
&gt; &gt;<br>
&gt; &gt; We have already obtained support from Russ Housley (thanks a lot,=
 Russ!);<br>
&gt; could we ask for one more review?<br>
&gt; &gt;<br>
&gt; <br>
&gt; Summary:<br>
&gt; <br>
&gt; It&#39;s great, I approve. Two comments follow; one on consistency of<=
br>
&gt; terminology that I believe is important and a one about algorithm choi=
ce that<br>
&gt; I don&#39;t expect to be addressed, but I had to make.<br>
&gt; <br>
&gt; Consistency in Editing:<br>
&gt; <br>
&gt; In general, the draft uses &quot;SHA256/192&quot; for the truncated SH=
A256, and<br>
&gt; &quot;SHAKE256-xxx&quot; for a SHAKE hash. That is to say, a slash is =
used with SHA and<br>
&gt; a hyphen with SHAKE. Sometimes this is inconsistent and it caused me<b=
r>
&gt; consternation when my brain interpreted a slash to mean SHA and a hyph=
en<br>
&gt; to mean SHAKE. Given that SHAKE starts with SHA and there&#39;s lots o=
f 256s<br>
&gt; being thrown around, it&#39;s really, really important to get this rig=
ht, else<br>
&gt; someone&#39;s going to make a mistake that will cause tears. I would e=
ven<br>
&gt; support something too clever by half like using &quot;SHA&quot; to mea=
n &quot;SHA256/192&quot;<br>
&gt; for further aid to the mildly dyslexic like me. There are also places =
where<br>
&gt; &quot;SHA256&quot; is written as &quot;SHA-256.&quot; For example, Sec=
tion 6 has all of these<br>
&gt; inconsistencies. Please be consistent.<br>
&gt; <br>
&gt; Whiny suggestion:<br>
&gt; <br>
&gt; There&#39;s a construction for a variable-length output version SHA512=
 called<br>
&gt; &quot;SHA512/t&quot; which is documented in &lt;<a href=3D"https://epr=
int.iacr.org/2010/548.pdf" rel=3D"noreferrer" target=3D"_blank">https://epr=
int.iacr.org/2010/548.pdf</a>&gt;.<br>
&gt; One a 64-bit processor, SHA512 is faster than SHA256, often like 30-40=
%<br>
&gt; faster. SHA512/t has changes to IVs to give different outputs. Section=
 3.1 of<br>
&gt; this draft explains why IV changes aren&#39;t needed, so this draft co=
uld easily<br>
&gt; have an option for a 192-bit truncation of SHA512. I know that at this=
 date, it&#39;s<br>
&gt; a big ask and arguably gilding the lily. It might even be a fine thing=
 for another<br>
&gt; document that throws that in, too. It might also be entirely too much =
to have<br>
&gt; even more options. I was unable to pull my hands back from the keyboar=
d,<br>
&gt; though, because the whole point of this draft is for smaller, faster s=
ignatures<br>
&gt; and the performance improvement of SHA512 leaps to mind. If you wanted=
<br>
&gt; to add that in, I&#39;d smile -- after all, the name of the draft is &=
quot;more<br>
&gt; parameters.&quot; I don&#39;t expect it.<br>
&gt; <br>
&gt; All in all, a nicely done, elegant draft.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0Jon<br>
<br>
</blockquote></div>

--000000000000cf215405bbab83f7--

