[Ssh] Re: PQ signatures - where do we want to end up?

Roumen Petrov <pkixssh@roumenpetrov.info> Tue, 28 April 2026 17:41 UTC

Return-Path: <pkixssh@roumenpetrov.info>
X-Original-To: ssh@mail2.ietf.org
Delivered-To: ssh@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B0461E4F18C3 for <ssh@mail2.ietf.org>; Tue, 28 Apr 2026 10:41:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777398101; bh=Wu0VZuqWymjj4OfvBleWoUIw5RIqdgbTmJ4kT48NFT0=; h=Date:Subject:To:References:From:In-Reply-To; b=gfAUPNoU26gRQtkACQPzHoPXCopnS/9XiVBO/wm1VInsSyxIyC2C90UvnvaZMJYRu trPFiKmzwCwIbmpP4y9M9qYqO83T4OObfgk3Zv9O1WQRUjnq4ZeBC8eWGFXsZlfO5Z z05VHfHjAocaNMXF1ERfZWDaXPj15uEyERxSMyGo=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=roumenpetrov.info
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 EwGWfKq6bCbm for <ssh@mail2.ietf.org>; Tue, 28 Apr 2026 10:41:41 -0700 (PDT)
Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (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 2D1BAE4F18AD for <ssh@ietf.org>; Tue, 28 Apr 2026 10:41:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roumenpetrov.info; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1An5wPoc/0/2/H2H6EdcNveAEl8Tdk0LArxkFpfsROs=; b=fjdvoTNTpyHMAMRuCF/oo+zfgx MMqcO8iiab+lZbjahWpgMFhFFMry07E6gcAUSDTFopOkMkGeLEhLFWaxR09PJDGAZkUI+sFX3KnsG VAaxedWm2/Z0pBXp3VjXdIpnIcSsxxINJoQXDL4wkWMVSLUBjHi7U1xkCzFB7YB4Obx80gEHsz24Q B5jsa4ycptAac/CXbp/WRgTig3kQWY6hOW5eZv445vESBwv28YrlQs8Epmw7/6wRW6tvW4I5Qq8qF LfvD7Nu3y8z9frU6bIhyFLB/fS4u0CkuizGkevL1Xr776GHpoH1CPAhjC/jvZGg+irNWkCqrUvZmN kIEQtk6g==;
Received: from [46.232.157.251] (port=62594 helo=[192.168.1.11]) by rila.superhosting.bg with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.99.1) (envelope-from <pkixssh@roumenpetrov.info>) id 1wHmR8-0000000Gwm4-0XIR for ssh@ietf.org; Tue, 28 Apr 2026 20:41:32 +0300
Message-ID: <aadd19c7-d4bf-424c-bf8e-e809f8997a6c@roumenpetrov.info>
Date: Tue, 28 Apr 2026 20:41:29 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: ssh@ietf.org
References: <f1964c88-5199-48f7-a23d-36c0328734c8@cs.tcd.ie> <CAFR824zaY1QzWSnT2z=SeFu5-QVzzOqMbuHXcnPU5wMsF+-pug@mail.gmail.com> <c5ca13e1845d433d817442d722098e7d@bofa.com>
Content-Language: en-GB
From: Roumen Petrov <pkixssh@roumenpetrov.info>
In-Reply-To: <c5ca13e1845d433d817442d722098e7d@bofa.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - rila.superhosting.bg
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roumenpetrov.info
X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info
X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info
X-Source:
X-Source-Args:
X-Source-Dir:
Message-ID-Hash: IARN77STGVN5EYHU55N7WRQ56H447CTD
X-Message-ID-Hash: IARN77STGVN5EYHU55N7WRQ56H447CTD
X-MailFrom: pkixssh@roumenpetrov.info
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Ssh] Re: PQ signatures - where do we want to end up?
List-Id: "The SSH mail list will allow discussions on improving aspects of the Secure Shell (SSH) protocol." <ssh.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ssh/BZL-gcTwQbcsuj8hZvIPdggdEa8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ssh>
List-Help: <mailto:ssh-request@ietf.org?subject=help>
List-Owner: <mailto:ssh-owner@ietf.org>
List-Post: <mailto:ssh@ietf.org>
List-Subscribe: <mailto:ssh-join@ietf.org>
List-Unsubscribe: <mailto:ssh-leave@ietf.org>

Hello Ryan,

На 28.04.26 г. в 19:00, Appel, Ryan написа:
> I do believe all the SSH RFCs only describe the way in which the public key is represented. I see no reference in any of the RSA or ECC definitions of keys that reference the way in which a private key is meant to be represented.
> 
> (https://datatracker.ietf.org/doc/html/rfc4253 - rsa and dsa)
> (https://datatracker.ietf.org/doc/html/rfc8709 - ed25519 and ed448)
> (https://datatracker.ietf.org/doc/html/rfc5656 - ecdsa)
> 
> ML-DSA public keys have to be represented as the fully expanded (compressed) key as defined in FIPS 204 due to the fact that the matrix A can be expanded from the public seed, and the vector t is computed from the private key (which can be stored in seed format as denoted by section 3.6.3 and 4).
> 
> Does it need to be the case where the newer specs specify the way in which ML-DSA keys (and others) are stored?

I do not think so.
Until now private keys are implementation dependent.
It seem to me cryptographic libraries store ML-DSA keys differently.

Only in PKCS#11 3.2 draft I could found ML-DSA standardised description.
The software that uses PKCS#11 ML-DSA keys is almost ready for use. It is tested by my PKIX-SSH MLDSA-DEMO implementation.


> 
> Thank you,
> 
> Ryan Appel, MS, BCS
> 
> Vice President; Security Architect
> GIS – Cyber Security Technology Architecture
> Bank of America
> 

Regards,
Roumen Petrov