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

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

Actually, I’d be happy either way (as these are ‘nits’, not real problems).  Those changes would be my suggestion.

From: Stanislav V. Smyshlyaev <[e-mail]>
Sent: Monday, June 15, 2020 4:01 AM
To: Scott Fluhrer (sfluhrer) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024)

Many thanks, Scott!

Therefore, you will be happy if the proposed change is applied, with the revised version of notes, dropping the sentences "The same applies for SHA3 ... " and "(Any attack that breaks...", – right?

Regards,
Stanislav


On Thu, 11 Jun 2020 at 22:48, Scott Fluhrer (sfluhrer) <[e-mail]<mailto:[e-mail]>> wrote:
The text looks correct, however I do have a few nits about the notes.  One is the reference to SHA3, which on a quick read might be misleading; here is some alterative text:

The reason is that SHAKE allows for meet-in-the-middle preimage attacks that reduce to a collision search on the internal state. These internal collision attacks do not affect the security of SHA3, because of the larger capacity used.

Alternatively, just drop the reference to SHA3, which isn’t relevent to XMSS.

The other nit is with the sentence that starts:

Any attack that breaks the relevant security definition must require computational resources…

That sort of statement always has an implicit assumption of the form “unless someone has a cryptographical result against the SHA-3 permutation”; while we are used to that sort of assumption, a causal reader might not be.  I don’t see what that sentence brings to the table; I’d suggest dropping it.

From: Crypto-panel <[e-mail]<mailto:[e-mail]>> On Behalf Of Stanislav V. Smyshlyaev
Sent: Thursday, June 11, 2020 1:57 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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