IETF Logo Mail Archive

[TLS] Re: Composite ML-DSA

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 15 April 2026 16:21 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 21A25DCE9EAD for <tls@mail2.ietf.org>; Wed, 15 Apr 2026 09:21:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776270106; bh=3CWAPqbCQHTIq9ORY35yu839nohY3NUBRofNBvS40Iw=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To; b=ZD5fiygBAsHlmB/XfMysv7xwqttNPwG1himuwEguxxeowp3jTajh7Ll2aIiuY5Zvl VmvkCBALoB1mI5TSOShtuC1262HdYug+f4tuY3AF35I+Yo+PyYGaMxMpzKqrav27Bi NmQiKxvy82wQeMkLsYYf+z/spidQmLXSnuL2vIqc=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y1eqj0kAy0G for <tls@mail2.ietf.org>; Wed, 15 Apr 2026 09:21:45 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (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 mail2.ietf.org (Postfix) with ESMTPS id 31FB3DCE8C9C for <tls@ietf.org>; Wed, 15 Apr 2026 09:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1776269847; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=3CWAPqbCQHTIq9ORY35yu839nohY3NUBRofNBvS40Iw=; b=UfmF1DTuT7UDTJVtYZZ+S3ipKTBmQs5ajfGwKSooUVptXeQTpwrUoW1kgnt8mniNE0exy OYYjZLK+N06Vj+GA8madPFA9iBi1fX51XJmCUaCD9CxAZwyGnetrQ6d2u85cccOJDyst+ML p9/taVkQCu9jXtLfH7ke2J+s9L0rkeY=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id 3F587937704; Thu, 16 Apr 2026 02:17:27 +1000 (AEST)
Date: Thu, 16 Apr 2026 02:17:27 +1000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <ad-6F830a4BQlu5R@chardros.imrryr.org>
References: <LV0PR21MB6623B48B1F3A05D745F5A79D8C242@LV0PR21MB6623.namprd21.prod.outlook.com> <ad0svakv_WUM3btz@chardros.imrryr.org> <CAF8qwaBU_YHWX2MsWeeaOJ8sutR1wMozvbiTJF5kyvTE8YjWWA@mail.gmail.com> <CACsn0c=GDta824UF7uJ3nw_4U_rT=XhYOGHRemMWa+2AdbsiAg@mail.gmail.com> <3a16c7c4-345e-48ce-af70-a3bf503c8caf@app.fastmail.com> <CACf5n7_0hdeHJXXucva9pb=+pjhcgveHRpjA8XAcXB3LsYUvaw@mail.gmail.com> <CAFpG3gcC+UfO7E=ADGhwr2En5PwipZiq_r6_RdqvmT-5nnh2jw@mail.gmail.com> <d69ba150-0257-4e64-9abb-9229d03a03a6@app.fastmail.com> <PA0P264MB69259DDB3DA252DC57E4B4EBB6222@PA0P264MB6925.FRAP264.PROD.OUTLOOK.COM> <MN2PR17MB40311654550B8396E7AC238BCD222@MN2PR17MB4031.namprd17.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <MN2PR17MB40311654550B8396E7AC238BCD222@MN2PR17MB4031.namprd17.prod.outlook.com>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 4X2Y7ZA7CS7UZOQQKPXACPGNMMARWR2H
X-Message-ID-Hash: 4X2Y7ZA7CS7UZOQQKPXACPGNMMARWR2H
X-MailFrom: ietf-dane@dukhovni.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: tls@ietf.org
Subject: [TLS] Re: Composite ML-DSA
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uVfxB_JGRBNYGvibdW3fFJtFYN8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Wed, Apr 15, 2026 at 03:58:18PM +0000, Salz, Rich wrote:

> Okay, this API (C code) is all over the place:
>       int EVP_SignFinal(EVP_MD_CTX *ctx,/* a context handle */
>             unsigned char *sig,unsigned int *s, /* buffersize and buffer */
>             EVP_PKEY *pkey /*the private key */
>       );
> 
> What do I change, compatibly, to allow multiple private keys?  A new API? For everything that takes “a” private key, it now takes “a set” of private keys?

Well, you don't do anything to allow "multiple" private keys, because a
composite key is a single key object with an opaque internal structure.
Only the algorithm's internal implementation knows that there are two
keys inside.

However, at least in OpenSSL, not every signature algorithm goes through
the same API.

Some, like RSA, are used via EVP_DigestSign{Init,Update,Final}(), while
others like Ed25519 use one of the one-shot signature APIs, or ML-DSA
which also supports an IUF interface over the as-yet undigested message.

Regardless, in no case would you have to explicitly worry about multiple
keys at the application layer.

A composite algorithm would have its own keygen/sign/verify routines
that looks much like that for EdDSA or ML-DSA (if Ed25519 and not
Ed25519ph is one of the compoments, you'd be limited to one-shot
signing).

-- 
    Viktor.  🇺🇦 Слава Україні!

v2.40.4 | Report a Bug | By Email | System Status