Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024)
"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Mon, 15 June 2020 08:01 UTC
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 9F8573A0AAB for <crypto-panel@ietfa.amsl.com>; Mon, 15 Jun 2020 01:01:38 -0700 (PDT)
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=unavailable 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 7RUNlUSiSwoZ for <crypto-panel@ietfa.amsl.com>; Mon, 15 Jun 2020 01:01:35 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 228B33A0AAD for <crypto-panel@irtf.org>; Mon, 15 Jun 2020 01:01:35 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id q19so18022196lji.2 for <crypto-panel@irtf.org>; Mon, 15 Jun 2020 01:01:35 -0700 (PDT)
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=wpFCXG30bqULBBMqSe9FzO6YxiL/9JEIzFM1Z0wgYHI=; b=YYEBI2B7ohDIJt/xdDHI11M+h5imfwc3B8Hw2anXpJE9MmUXOjAwjqL6p5qaQ2x7dw /peqdz4tyPpmymZIft/yZ4lwxC9YfIXmW9KeK5sT67rGUCGrpOrxm5pM1reJt/z1BB04 qzCkASM0RIBVvZCy01fNMXhWugfM2Dt2wFlmuYnesGAEtlmsOV+pTsmU8TpIeYpzRlPu fYg9mjX4QE+QaVu9Bo2IDGH5DeOVhZ1PGVbkDIxol6WakHJkfOZBY5rcqVwsfGOfI+IB cseSvHwgTK+8AEmFwWsBwq6yfwJEe6qf9RmO3P3EDMZ2bFJsHIYycAwlkHOoUKP+7Rpo coog==
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=wpFCXG30bqULBBMqSe9FzO6YxiL/9JEIzFM1Z0wgYHI=; b=OCvehXsH+Zv37gO8MUj04NRApwlPjoHodcEfz5GAAXu7r/LONCXMhdQ4AHZOKXxASS Sppj1l7MBY/XhX1OORkY6z20RiyFRGcSRzwa/7NkcBgl/NufYfYIDqjAEGmFC5DELkFN BRmiZq7njF8pVr41KdBCxcOwx4tH+qpxTiiXlDA6mGvZM4+BWc/mMEhPs34iGZLcSmoq aAID/4YgKTgVX1NLD+HldBxwVCeHe1jqlrTrMaz9AhjDBTG3h8ifQG8S6odkzc9g/Kvf 5tXWnNDUzw9yq6rkalrXW5SyKnAKLAiP8RCcPkSWOBIRCGTSCyU2KGOVup0X/42czl4d Fn7Q==
X-Gm-Message-State: AOAM531O/fqtprELM3blaejHQzFb/xrZU3ns9Q4tLRR3Snml1MwVYWJU fM6IYZ1gtmOtHLhgzFsbWFZDejq3B4yrSdWEplU=
X-Google-Smtp-Source: ABdhPJxyHK12NzR0uGQ/v2YoW9phyyj5XTy85FteAN6jeIOI3U5AcCK/R39Nta1w0o66yXR2uraP1UqkD9vbR4fb8MI=
X-Received: by 2002:a2e:974a:: with SMTP id f10mr12872084ljj.283.1592208093085; Mon, 15 Jun 2020 01:01:33 -0700 (PDT)
MIME-Version: 1.0
References: <20200318130152.57FD7F4071D@rfc-editor.org> <C7F982AB-F281-4AD2-BBB4-3C494CAED996@csperkins.org> <CAMr0u6=Qy-LRg7Ge5+TuaEivNAfSp_ncG9D2_nOQKOC=89RjtA@mail.gmail.com> <BN7PR11MB2641199090BA16B1DE9C1375C1800@BN7PR11MB2641.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2641199090BA16B1DE9C1375C1800@BN7PR11MB2641.namprd11.prod.outlook.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Mon, 15 Jun 2020 11:01:22 +0300
Message-ID: <CAMr0u6mg91h6DTWrmY7FmLnX3KP8LO+UEgvds9O9o_sD0M7syw@mail.gmail.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Cc: "crypto-panel@irtf.org" <crypto-panel@irtf.org>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cc04a805a81ad55e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/bTAvzUbCKp217q9cknVIyOjx9D4>
Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024)
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: Mon, 15 Jun 2020 08:01:39 -0000
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) <sfluhrer@cisco.com> 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 <crypto-panel-bounces@irtf.org> * On Behalf Of *Stanislav > V. Smyshlyaev > *Sent:* Thursday, June 11, 2020 1:57 PM > *To:* crypto-panel@irtf.org > *Cc:* cfrg-chairs@ietf.org > *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* <csp@csperkins.org> > Дата: сб, 6 июня 2020 г. в 16:03 > Тема: Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) > Кому: <cfrg-chairs@ietf.org> > > > > 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 <rfc-editor@rfc-editor.org> > > *Subject: **[irsg] [Technical Errata Reported] RFC8391 (6024)* > > *Date: *18 March 2020 at 13:01:52 GMT > > *To: *ietf@huelsing.net, dbutin@cdc.informatik.tu-darmstadt.de, > ietf@gazdag.de, ietf@joostrijneveld.nl, mohaisen@ieee.org, irsg@irtf.org > > *Cc: *ietf@huelsing.net, rfc-editor@rfc-editor.org > > > > 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 <ietf@huelsing.net> > > 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 > > > > >
- [Crypto-panel] Fwd: [irsg] [Technical Errata Repo… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] Fwd: [irsg] [Technical Errata … Scott Fluhrer (sfluhrer)
- Re: [Crypto-panel] Fwd: [irsg] [Technical Errata … Scott Fluhrer (sfluhrer)
- Re: [Crypto-panel] Fwd: [irsg] [Technical Errata … Stanislav V. Smyshlyaev
- Re: [Crypto-panel] Fwd: [irsg] [Technical Errata … Stanislav V. Smyshlyaev
- Re: [Crypto-panel] Fwd: [irsg] [Technical Errata … Scott Fluhrer (sfluhrer)
- Re: [Crypto-panel] Fwd: [irsg] [Technical Errata … Stanislav V. Smyshlyaev