[jose] Re: [COSE] Re: Re: Algorithm identifiers for pre-hashing in two-party signing?

Emil Lundberg <emil@yubico.com> Fri, 04 October 2024 09:46 UTC

Return-Path: <emil@yubico.com>
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 CE8D9C14F71B for <jose@ietfa.amsl.com>; Fri, 4 Oct 2024 02:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yubico.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 GKDjMO22Y_7t for <jose@ietfa.amsl.com>; Fri, 4 Oct 2024 02:46:33 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B09C15108C for <jose@ietf.org>; Fri, 4 Oct 2024 02:46:33 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-37ccf0c0376so1266401f8f.3 for <jose@ietf.org>; Fri, 04 Oct 2024 02:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yubico.com; s=google; t=1728035191; x=1728639991; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x/Bphc5I4sHwnNg5bb4IT5uwe1r+lvmbMah3+2/MyqA=; b=JT0WonuFpd6blsiZhr/Wqi6IeSFH5uBbKYkX+yCfXdmC+dpbWCY8cqdb3WJuFgjRwm +pb2H4E8lQTuUUC0/ZXfQNbpaPKZoKGuwsMdKAYKEHd7+apY187fifp79X7tWX0g1peT IHMpUS2Ow7v33cqORv6sbEmNDePwDHAfMRL/EDaNeNsVYpaL3vJioHmF0etrHkZksCQp oLw4eIF6FVc6TWpSyztstf8ZbNNGC1RG1iZkJJy7iN6MzhcQhJEztQj4zfD/7ANT6t7h T/lD2boVssHFr+J6EUPwdrXdm4ShYgSV4FI7QA6t1+bmgmPcVznVjXuQptHDoqcvju97 BoIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728035191; x=1728639991; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x/Bphc5I4sHwnNg5bb4IT5uwe1r+lvmbMah3+2/MyqA=; b=w+ZjGo7SXeY+AjCgjwxnKWUtEpEE7r8txTVweNo0pwySSMo9W3i6dqvZP8PJEBslJw xrNf+foCVpm3BhhAz1eII+uVSYDH/Koh1QUtVoT0rI+BgFDmxCbggXb7ug/IrgVWIr/c FrZM4cb1mOUP1M2XOjs/synQcSZuvGAkeQk5nfIq/qMSkaXlVv4+zFoFPjFBgN3Iz5mI D3qK9NbdDIvpbgkr4+890b5Q/SiQeCAZy2wJfmdOsFVpUVvax7VZixTG0UTt1o3wQUjX sV7H415+jS9F99tCZOCcjmApYQZOSxGIsbYrkIzTQlpDTkFMNHswSKTK2YDWRtSl3gPm 45RA==
X-Forwarded-Encrypted: i=1; AJvYcCUQgaq8xVsWaum28z9vDJs0nvZ+o5QwIKjOxHZ+/LYQFa8h+1QIt6pVP5LocZr5QsdgEoF2@ietf.org
X-Gm-Message-State: AOJu0YwpFjY3CZjz4L2ClYVJ6hsgKqZXAZCefi4IpMi7/NLBUvZ5dfUj nR4waqhhRApmgeAXkyNJNIXccKzbInp8kM4UI+HR9dQvUz/SjkNkxeBbYrRKoMf4S3rXEZ9AB3o akoveV3IUUT+woPLI0bHC7P5GFNgB/X/DtoGK0GjJtVZ2hMSDosU=
X-Google-Smtp-Source: AGHT+IHFvjc/otWwxbGrAsT2zDsSlygNjW8TAHhACf8AefbXlU2yTOIGh8caqo2GRpgeMXxgZzGVpD2oME5EdahkzhI=
X-Received: by 2002:adf:ab14:0:b0:374:bd93:9bd4 with SMTP id ffacd0b85a97d-37d0e8e66ccmr1388679f8f.56.1728035191393; Fri, 04 Oct 2024 02:46:31 -0700 (PDT)
MIME-Version: 1.0
References: <CANMnvkxiVppxz5Pm2dWaMVJTB229kTpw9f8Si-WmY0jkrBP=wg@mail.gmail.com> <SJ0PR02MB743976C3214FBB090F2D7D71B7682@SJ0PR02MB7439.namprd02.prod.outlook.com> <CANMnvkyxaSzhv+BHBfBiW9oJ4KuOFaVS4Ef3PJnEOFv_iSUbfw@mail.gmail.com> <CAN8C-_JwcozwHh8mK2UfbCa_ZP+go_QJa67OTk+GVK0=Zdb_Zg@mail.gmail.com> <CANMnvkxD_H93N_8TvANRb9oV=Mx0tn5nm9ekRd_YgA3=s38T6w@mail.gmail.com> <Zv8Df6oOSovLCaUN@LK-Perkele-VII2.locald>
In-Reply-To: <Zv8Df6oOSovLCaUN@LK-Perkele-VII2.locald>
From: Emil Lundberg <emil@yubico.com>
Date: Fri, 04 Oct 2024 11:46:15 +0200
Message-ID: <CANMnvkyMrD3-rDEpErQC3FFKcmcx3riYB1UNqC25yKnu+3OC6g@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="000000000000be2fb40623a38b9f"
Message-ID-Hash: CIBPRAHEUI5SEZGFEWH4ZBM2BR5PRT6A
X-Message-ID-Hash: CIBPRAHEUI5SEZGFEWH4ZBM2BR5PRT6A
X-MailFrom: emil@yubico.com
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: cose <cose@ietf.org>, "jose@ietf.org" <jose@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [jose] Re: [COSE] Re: Re: Algorithm identifiers for pre-hashing in two-party signing?
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/1gyXRY_pjsfe74XPTZztGMPMUmc>
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>

Thank you Ilari -

For ML-DSA, it is possible to calculate the internal hash (mu; 64 bytes)
> from the public key and message.


I agree this is possible, with the caveat that it moves control of the
domain separation tags away from the "signer" (the one holding the private
key) to the "digester" (the one computing the initial digest), because the
domain separation tags are applied before hashing to μ in step 6. In our
use case the "digester" is somewhat trusted, but not trusted with access to
the private key, so prefer to give it as little influence over the signing
procedure as possible. Since the same spec already defines HashML-DSA, I
think it's safer to restrict ourselves to that since that keeps the
"signer" in control of the domain separation tags.

For PureEdDSA (and SLH-DSA), to get two-party signing with O(1)
> communication, interactive (two-round) protocol is required. This is
> possible exploiting the fact that verifiers can not detect if the
> first message-dependent value has been replaced by random value.
> However, this is playing with fire (the protocol must never fork
> and random numbers have to be absolutely perfect).


Hm, interesting. I took another look at the EdDSA algorithm
<https://www.rfc-editor.org/rfc/rfc8032#section-3.2> and I agree that
pre-hashing PureEdDSA would indeed be possible like you describe, but with
the *enormous* caveat that it gives the "digester" access to the private
scalar:

The EdDSA public-private key pair is (A, k):

h_bits = H(k)
s = bits_to_scalar(h_bits)
A = [s]B


Now consider a two-party signing protocol like this:

Digester computes:
r = H(h_bits || M)
phm = PH(M)

Digester transmits r, phm to Signer.


Signer computes:
R = [r]B
S = (r + H(R || A || phm) * s) mod L


Assume the "signer" returns the signature to the "digester" which relays it
to the intended recipient. We can therefore assume the "digester" knows the
public values A, R and S.
The "digester" can now recover the private scalar:

S - r = H(R || A || phm) * s
(S - r) * ModInv(H(R || A || phm)) = s


Thus the "digester" now knows the private scalar s and can use it to forge
signatures.

So yes, I agree this is "playing with fire" and would not work with our
intended use case where the "digester" is not supposed to know the signing
private key. Therefore the mockup document includes examples for Ed25519ph
and HashML-DSA, but not "pure" Ed25519 or ML-DSA:
https://yubico.github.io/arkg-rfc/cose-two-party-sign-algs/draft-bradleylundberg-cfrg-arkg.html

Cheers,

Emil Lundberg

Staff Engineer | Yubico <http://www.yubico.com/>




Den tors 3 okt. 2024 kl 22:50 skrev Ilari Liusvaara <
ilariliusvaara@welho.com>:

> On Thu, Oct 03, 2024 at 08:00:16PM +0200, Emil Lundberg wrote:
> >
> > If you don't want domain separation, then you simply need to identify
> > > registered algorithms,
> >
> >
> > For the keys and the resulting cryptograms, yes. But that's not what my
> > question was about.
> >
> > [...] where you can do the pre hash part separate from the signing part.
> >
> > [...]
> >
> > [...] but be careful, this does not generalize to other COSE digital
> > > signature schemes, like Ed25519 / EdDSA.
> >
> >
> > This is what I'm asking about - or, more precisely, how to communicate
> > where the separation happens between "pre hash part" and "signing part".
> > Like you point out, there's no way to describe that generically,
> especially
> > since some algorithms like PureEdDSA and ML-DSA *can't* be separated like
> > that.
>
> For ML-DSA, it is possible to calculate the internal hash (mu; 64 bytes)
> from the public key and message.
>
> For PureEdDSA (and SLH-DSA), to get two-party signing with O(1)
> communication, interactive (two-round) protocol is required. This is
> possible exploiting the fact that verifiers can not detect if the
> first message-dependent value has been replaced by random value.
> However, this is playing with fire (the protocol must never fork
> and random numbers have to be absolutely perfect).
>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list -- cose@ietf.org
> To unsubscribe send an email to cose-leave@ietf.org
>