[openpgp] Re: pure vs. pre-hash in FIPS 204 and 205

Daniel Huigens <d.huigens@protonmail.com> Thu, 29 August 2024 15:32 UTC

Return-Path: <d.huigens@protonmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC76C180B73 for <openpgp@ietfa.amsl.com>; Thu, 29 Aug 2024 08:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbRwC8q6McpX for <openpgp@ietfa.amsl.com>; Thu, 29 Aug 2024 08:32:49 -0700 (PDT)
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE41EC18DBB9 for <openpgp@ietf.org>; Thu, 29 Aug 2024 08:32:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724945566; x=1725204766; bh=EbeWhpu063Ep72V1qXsQMou9tc7yerttL9QPW8lCNCQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=tPXa8BwnRhsx33N1g4nNKiIs29ZfAEGEKoWFn3eq3uwkU/ucNOfw8FzdlC9KhEKK7 t4iZb4qOE02OceqCWop7C3dbKejVLiN9FuAxBIYeaDElmO3x3328w7gkgk4klHK7b2 4IG7QQB76QkKcU7V/ivz82TbwbUlwyZvSKIqyJg6Ggdshf7jJ++yqUZzD9ioAvYWsm SGve5/+Jfiec/X99YqYMcyqf5EZ8gFfPFpI+HlF+neSCeYTC2dwQ4usOdUmLxJvMHW ud2lu8VjcIai2YbTHerV76dXdie9EPsIsxN4ZUWkEARgy8s9L1y80m3AJa0UEYmziM RoKP/Hi3kCAVg==
Date: Thu, 29 Aug 2024 15:32:44 +0000
To: Akhil CM <akhilacm=40proton.me@dmarc.ietf.org>
From: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: <omd_KoB7p1D--386Pf32vrA1P5vqDQ86UiMSIiLx50JPWTRkttnlTFJ2GPR-Gq4hovTYhGO_Q9bA66y0yalOtCGF9nsTG0Vf8eG08h8Bq-U=@protonmail.com>
In-Reply-To: <gp_qhnxiYq_pgzpw26Gw5lC53i2aOD1tik9Lrprf0yhURin012f3YvwxS-8mGXOX7ObRAiMqjBkyyxiC8vkwuMMg0Kng4dSOI4Edwww0v4I=@proton.me>
References: <gp_qhnxiYq_pgzpw26Gw5lC53i2aOD1tik9Lrprf0yhURin012f3YvwxS-8mGXOX7ObRAiMqjBkyyxiC8vkwuMMg0Kng4dSOI4Edwww0v4I=@proton.me>
Feedback-ID: 2934448:user:proton
X-Pm-Message-ID: f3a3738e6e3c38ee1033d3e20e457ae9fdd8591f
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_of3PlMJHEHKwKoV6OZx2XAzZHGIRNqWd8eg39KSSbDw"
Message-ID-Hash: QNTDS47JPWAD7WLJ57DDV3VYPY2N4GLS
X-Message-ID-Hash: QNTDS47JPWAD7WLJ57DDV3VYPY2N4GLS
X-MailFrom: d.huigens@protonmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "openpgp@ietf.org" <openpgp@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [openpgp] Re: pure vs. pre-hash in FIPS 204 and 205
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/tBcREi0_Jym5CZgLlz6TWPvcD90>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

Hi Akhil,

On Wednesday, August 28th, 2024 at 02:46, Akhil CM wrote:

> I think this is the part where the common misunderstanding is. It is more accurate to to say thatpre-hash version of ML-DSAdoes a "single hashing" step (rather than calling it "extra") before passing the message to the signing algorithm used by the "pure" variant.

Well, even the pure version of ML-DSA has a hashing step internally (see section 6.2 of FIPS 204). So I think saying that HashML-DSA does an extra hashing step (compared to the pure version) is accurate :) But yes, of course there is not an extra hashing step compared to using HashML-DSA and removing the hashing step at the application level (or, as Falko proposed, passing the hash from the application level and asking the cryptography library to compute HashML-DSA without doing the extra hashing step that's normally there, by using the already-computed hash digest instead).

> In the same section 5.4, as Daniel quoted in a reply and I re-quoted above, they talk about the hashing of the message at the application level and continues to add that in such cases the application level hash may be signed directly. So, from the context it can be considered that the following are equivalent or similar (not to be confused with same or identical):
>
> - Application level hashing + signing
> - pre-hash variant signing

Yes, indeed. However, even though they are roughly equivalent, both FIPS 204 and RFC 8032 seem to recommend using the first one where possible.

> In my opinion, the best way to go about this so as to provide minimal confusion between various literatures would be to do one of the following:
>
> - Explicity provide three categories: "pure", "pre-hash" and "hash at application level" + "pure"

I'm fine with that, although I think nobody has proposed the first option (pure signing without hashing).

> - Mention "hash at application level" + "pure" as an alternate to "pre-hash" once, as done in FIPS 204, and then continue to use the terminology "pre-hash" whenever a hashed message is passed to the signing algorithm used by the "pure" version

I don't think that would clarify things but rather confuse them, as technically speaking, "hash at application level + pure" and "pre-hash" are still different and produce a different result (even though they are equivalent in security for the purposes of OpenPGP). So for clarity I think it's better to spell it out as you did (or shortened to "hash + pure ML-DSA" vs "HashML-DSA"), at least until a decision has been made :)

Best,
Daniel