[jose] Re: [CFRG] Do we have unsafe uses of Ed448 and Ed25519? Fix Ed448?

Daniel Huigens <daniel.huigens@proton.ch> Thu, 12 September 2024 18:41 UTC

Return-Path: <daniel.huigens@proton.ch>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7845AC14F6FA; Thu, 12 Sep 2024 11:41:32 -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, 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=proton.ch
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 I2AUxsmcxnNI; Thu, 12 Sep 2024 11:41:27 -0700 (PDT)
Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18]) (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 C23BCC14F700; Thu, 12 Sep 2024 11:41:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.ch; s=4rmrgx5sevdazcs3zu2drrubhy.protonmail; t=1726166484; x=1726425684; bh=kfrfSHEGBn4epVao9ojDiJt5YLTl/Mz/Xa7C11v4nHI=; 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=G8Fxo+LARfJqcEQynrHXGKZg5MZcBsE5hiLuU4t3fjsYhYHR7VcRep6UdQk87zW8P Otug6GHm+d9UIe8nIcdBmDmzQQVhq2IJ3dExFT5gQHU/OCaU9LmG8zDWL1dwIeQ1xl OVi8dNPjhJz8QH5uSuN1rybnNLaytGvJe3AzfsbQ63sITEvEx+JFaS7ds/Q0FJjdmb U+CRwseKXcyz4d0kGyrGCeR6cNsilFShLCkjSNiXAHUg5gWNCPvPkDySd65pJy4fxt rzAmcgDCEfteNod0DimBmksx3O8D8R9O1DBmWp6Iamc5Lj9wwN6du+U6+e2nQpu/fw 9gc0R7BgJcb4Q==
Date: Thu, 12 Sep 2024 18:41:21 +0000
To: Phillip Hallam-Baker <phill@hallambaker.com>
From: Daniel Huigens <daniel.huigens@proton.ch>
Message-ID: <EFRK10NjF9PY9HVQWEHtO59GMQTpUu2nJ1bFb3_DLRzAwo6Wr-tiWMqXmsZbCQHeYzQ9lsqDzNWf_vjndqDseaexeBLAnbpy0WsfRFMAONE=@proton.ch>
In-Reply-To: <CAMm+LwgWerSbRAg01jYbRDEbcD5U1tzmLJFS0SQ-BhYRt3zEHA@mail.gmail.com>
References: <CAMm+Lwhqn4Jb6+ngpn7XgewMPhp_m30sVmHHWpGOzgQL-Jb-Gg@mail.gmail.com> <7UBoaC8dyojecRBPaTY-ox4-kUc97lmYVs7CCbK1-pSSOGciGEGpMDrmbtcvXaVwck_g450IA1NkMmeu4drw-TsIJbANOyNJTk85HTRSgLA=@proton.ch> <CAMm+LwgWerSbRAg01jYbRDEbcD5U1tzmLJFS0SQ-BhYRt3zEHA@mail.gmail.com>
Feedback-ID: 37000915:user:proton
X-Pm-Message-ID: e32b033ecf19e4f5959ce15d2b1a7a0057c11f04
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_vFCYXUlR44GcryJqjQfNUOBetBYqinGji49dGqFekbU"
Message-ID-Hash: MQU4TONYPTLHQFDXAP3DR45LV6AEKOMZ
X-Message-ID-Hash: MQU4TONYPTLHQFDXAP3DR45LV6AEKOMZ
X-MailFrom: daniel.huigens@proton.ch
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IRTF CFRG <cfrg@irtf.org>, jose@ietf.org, cose WG <cose@ietf.org>, SPASM <SPASM@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: [CFRG] Do we have unsafe uses of Ed448 and Ed25519? Fix Ed448?
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/IsaOW-k-lj-ZtG1-qq5F4AxxgXQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

Hi Phillip,

On Thursday, September 12th, 2024 at 19:48, Phillip Hallam-Baker wrote:

> The underlying problem here and the one that I think is causing the confusion is that Ed448 or ML-DSA both specify a mode that is being refered to as 'prehashed' but they are not the same thing. ML-DSA is a mode that turns ML-DSA into a drop in replacement for RSA with the exact same affordances: bring your existing hash and it gets signed. Ed448 is 'hash your data with SHAKE256 and give me that digest'.

That is not what the specs say. Both FIPS 204 and RFC 8032 say that the pre-hash variant accepts a message​ (not a hash of a message) and hashes the message (inside the function) before passing it to the internal signing function. The only difference is that HashML-DSA also has a parameter to say which hash function should be used, whereas in HashEdDSA it's hardcoded.

Of course, you could reinterpret the functions that the specs define as ones that accept a hash digest, and implement it that way, but then that is what introduces the risk of using the wrong hash function, not the way they're defined in the specs.

And note that strictly speaking, this risk exists for both algorithms, if you implement it like that: it's then equally possible in HashML-DSA to pass a hash digest generated using a hash function that doesn't match the one you say you used, as it is in HashEdDSA to use a hash function different than the one that the documentation says to use.

---

I actually think a lot of this confusion comes from naming: if they had called HashML-DSA and HashEdDSA the "additional hash variants", or "one-pass/streaming variants", rather than the "pre-hash variants", it would have been clearer; and the term "pre-hashed variants" could then be used for the variant where you pass a hash digest rather than a message (if we need such a construct at all, that is - as again I'd argue that in that case you can just use the pure variant with a context string).

Best,
Daniel