Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024)

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

I volunteer; however I can’t read the link.  Did you send it correctly?

Actually, the corrected text you include below looks decent (although the discussion of SHA3 may be a bit misleading – SHA-3 has more than n/2 bits of security, which someone might assume from a quick reading of “The same applies for SHA3…”).

I’d want to see the full errata before I place my seal of approval, of course.

From: Crypto-panel <[e-mail]> On Behalf Of Stanislav V. Smyshlyaev
Sent: Thursday, June 11, 2020 1:57 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024)

Dear Crypto Review Panel members,

There is a need to validate the following errata:
https://www.rfc-editor.org/errata/eid6024<https://www.rfc-editor..org/errata/eid6024>

Any volunteers?

Regards,
CFRG chairs



---------- Пересылаемое сообщение ---------
От: Colin Perkins <[e-mail]<mailto:[e-mail]>>
Дата: сб, 6 июня 2020 г. в 16:03
Тема: Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024)
Кому: <[e-mail]<mailto:[e-mail]>>

Hi CFRG chairs,

Can you discuss, and review with the RG if necessary, and let me know  if the following errata should be marked as verified.

Thanks,
Colin




Begin forwarded message:

From: RFC Errata System <[e-mail]<mailto:[e-mail]>>
Subject: [irsg] [Technical Errata Reported] RFC8391 (6024)
Date: 18 March 2020 at 13:01:52 GMT
To: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>

The following errata report has been submitted for RFC8391,
"XMSS: eXtended Merkle Signature Scheme".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6024

--------------------------------------
Type: Technical
Reported by: Andreas Hülsing <[e-mail]<mailto:[e-mail]>>

Section: 5

Original Text
-------------
This section provides basic parameter sets that are assumed to cover most relevant applications.  Parameter sets for two classical security levels are defined.  Parameters with n = 32 provide a classical security level of 256 bits.  Parameters with n = 64 provide a classical security level of 512 bits.  Considering quantum-computer-aided attacks, these output sizes yield post-quantum security of 128 and 256 bits, respectively.

Corrected Text
--------------
This section provides basic parameter sets that are assumed to cover most relevant applications. Parameter sets for two classical security levels are defined using the cryptographic functions SHA2 and SHAKE.  Parameters with SHA2 and n = 32 provide a classical security level of 256 bits. Parameters with SHA2 and n = 64 provide a classical security level of 512 bits.  Considering quantum-computer-aided attacks, these parameters yield post-quantum security of 128 and 256 bits, respectively. Parameters with SHAKE and n = 32 provide a classical security level of 128 bits.  Parameters with SHAKE and n = 64 provide a classical security level of 256 bits.  Considering quantum-computer-aided attacks, these parameters yield post-quantum security of 86 and 170 bits, respectively.

Notes
-----
Traditionally, a hash function with n-bit outputs is assumed to have n-bit security against classical preimage and second-preimage attacks, and n/2-bit security against classical collision attacks. For adversaries with access to a quantum computer, these bounds change to n/2 and n/3 bits when only counting queries to the hash function. This also applies to SHA2 and SHA3. In contrast, SHAKE follows a different reasoning. SHAKE with an internal state of n bits and an output length of n bits achieves n/2 bit security against classical preimage, second-preimage and collision attacks. For quantum attacks security changes to n/3 bits. The reason is that SHAKE allows for meet-in-the-middle preimage attacks that reduce to a collision search on the internal state. The same applies for SHA3 but for SHA3 a bigger internal state is used.

In consequence, SHAKE-128 cannot provide more security than NIST post-quantum security level II (Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for collision search on a 256-bit hash function (e.g. SHA256 / SHA3-256)).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8391 (draft-irtf-cfrg-xmss-hash-based-signatures-12)
--------------------------------------
Title               : XMSS: eXtended Merkle Signature Scheme
Publication Date    : May 2018
Author(s)           : A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A.. Mohaisen
Category            : INFORMATIONAL
Source              : Crypto Forum Research Group
Area                : N/A
Stream              : IRTF
Verifying Party     : IRSG