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

["Stanislav V. Smyshlyaev" <[e-mail]>]

Thank you, Scott!

Here is the correct link: https://www.rfc-editor.org/errata/eid6024

Regards,
Stanislav

On Thu, 11 Jun 2020 at 22:12, Scott Fluhrer (sfluhrer) <[e-mail]>
wrote:

> 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]>
> Дата: сб, 6 июня 2020 г. в 16:03
> Тема: Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024)
> Кому: <[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]>
>
> *Subject: **[irsg] [Technical Errata Reported] RFC8391 (6024)*
>
> *Date: *18 March 2020 at 13:01:52 GMT
>
> *To: *[e-mail], [e-mail],
> [e-mail], [e-mail], [e-mail], [e-mail]
>
> *Cc: *[e-mail], [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]>
>
> 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
>
>
>
>
>