[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3bb08a53-0387-41a7-98bd-31054edf48cd@linux.ibm.com>
Date: Fri, 7 Nov 2025 14:19:23 -0500
From: Stefan Berger <stefanb@...ux.ibm.com>
To: David Howells <dhowells@...hat.com>
Cc: Simo Sorce <simo@...hat.com>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Ignat Korchagin <ignat@...udflare.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Stephan Mueller <smueller@...onox.de>, 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
On 11/7/25 5:03 AM, David Howells wrote:
> 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.
Correct. It was supposed to become GPLv2 + Apache 2.
>
> David
>
>
Powered by blists - more mailing lists