[Cfrg] [Errata Verified] RFC8391 (6024)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 23 June 2020 08:16 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22103A17DD; Tue, 23 Jun 2020 01:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 6y42tCGQHG9N; Tue, 23 Jun 2020 01:16:42 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17BF3A17DF; Tue, 23 Jun 2020 01:16:41 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 927A7F407B8; Tue, 23 Jun 2020 01:16:30 -0700 (PDT)
To: ietf@huelsing.net, ietf@huelsing.net, dbutin@cdc.informatik.tu-darmstadt.de, ietf@gazdag.de, ietf@joostrijneveld.nl, mohaisen@ieee.org
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: csp@csperkins.org, irsg@irtf.org, cfrg@irtf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200623081630.927A7F407B8@rfc-editor.org>
Date: Tue, 23 Jun 2020 01:16:30 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Ec3YlAnUkuZS9ZPQHXNJMHW20KQ>
X-Mailman-Approved-At: Thu, 25 Jun 2020 02:05:20 -0700
Subject: [Cfrg] [Errata Verified] RFC8391 (6024)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2020 08:16:47 -0000

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

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

--------------------------------------
Status: Verified
Type: Technical

Reported by: Andreas Hülsing <ietf@huelsing.net>
Date Reported: 2020-03-18
Verified by: Colin Perkins (IRSG)

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. 
   
 In consequence, SHAKE-128 cannot provide more security than NIST post-quantum security level II.

(Errata submitted by Andreas Hülsing; notes slightly revised after Crypto Forum review by Scott Fluhrer; verified by CFRG Chairs and IRTF Chair)

--------------------------------------
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