[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3917048.kQq0lBPeGt@tauon>
Date: Fri, 07 Nov 2025 11:23:46 +0100
From: Stephan Mueller <smueller@...onox.de>
To: Stefan Berger <stefanb@...ux.ibm.com>, David Howells <dhowells@...hat.com>
Cc: dhowells@...hat.com, Simo Sorce <simo@...hat.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Ignat Korchagin <ignat@...udflare.com>,
Herbert Xu <herbert@...dor.apana.org.au>, torvalds@...ux-foundation.org,
Paul Moore <paul@...l-moore.com>, Lukas Wunner <lukas@...ner.de>,
Clemens Lang <cllang@...hat.com>, David Bohannon <dbohanno@...hat.com>,
Roberto Sassu <roberto.sassu@...wei.com>, keyrings@...r.kernel.org,
linux-crypto@...r.kernel.org, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: Module signing and post-quantum crypto public key algorithms
Am Freitag, 7. November 2025, 11:03:49 Mitteleuropäische Normalzeit schrieb
David Howells:
Hi David,
> Stefan Berger <stefanb@...ux.ibm.com> wrote:
> > On 6/16/25 1:27 PM, Simo Sorce wrote:
> > > Of course we can decide to hedge *all bets* and move to a composed
> > > signature (both a classic and a PQ one), in which case I would suggest
> > > looking into signatures that use ML-DSA-87 + Ed448 or ML-DSA-87 + P-521
> > > ,ideally disjoint, with a kernel policy that can decide which (or both)
> > > needs to be valid/checked so that the policy can be changed quickly via
> > > configuration if any of the signature is broken.
> >
> > FYI: based on this implementation of ML-DSA-44/65/87
> >
> > https://github.com/IBM/mlca/tree/main/qsc/crystals
>
> The problem with that is that the Apache-2 licence is incompatible with
> GPLv2. Now, it might be possible to persuade IBM to dual-license their
> code.
The code used as a basis for the current approach (leancrypto.org) offers
hybrids with ED25519 and ED448) including the X.509/PKCS7 support.
However, please note that the X.509 specification for storing hybrid public
keys is not yet completed and there is still some work on the draft IETF
standard [1].
Side note: the leancrypto code base uses the Linux kernel X.509/PKCS7 parser
code where the relevant handler functions (see [2]) could be relatively
quickly transplanted into the kernel if needed.
[1] https://lamps-wg.github.io/draft-composite-sigs/draft-ietf-lamps-pq-composite-sigs.html
[2] https://github.com/smuellerDD/leancrypto/blob/master/asn1/src/
x509_cert_parser.c
Ciao
Stephan
Powered by blists - more mailing lists