A Pragmatic Leap

Sun, 9 Nov 2025

Code’s being prepared for the 6.19 kernel, which integrates ML-DSA (Module-Lattice-Based Digital Signature Algorithm), also known as CRYSTALS-Dilithium, which NIST finalized as part of the PQC standardization process, to validate the digital signatures on kernel modules before they’re loaded.

The patch, which adds over 5,000 lines of code, is a port of the signature verification code from Leancrypto. A note included in the patch is that: “The keypair generation and signature generation are not included.” This is because kernel module signing is a separate process. The kernel’s only job at runtime is to verify that a module’s signature is valid before loading it into memory.

A second detail is that the initial patch is “pure C”, which provides a universal, portable implementation that will run on every architecture the kernel supports. This ensures the kernel’s ready to verify PQC-signed modules long before PQC-specific hardware acceleration is available.

Understanding the Need for Migration

The security of classical public-key algorithms, such as RSA and ECDSA, is based on the extreme difficulty of solving specific mathematical problems: integer factorization (for RSA) and the discrete logarithm problem (for ECC). For classical computers, these problems are practically unsolvable.

In 1994, mathematician Peter Shor developed an algorithm that runs on a sufficiently powerful quantum computer. Shor’s algorithm solves both of these “hard” problems in polynomial time, meaning it can render both RSA and ECC completely insecure. The day a machine capable of this arrives is referred to as “Q-Day.”

The threat isn’t just a future problem. Adversaries are believed to be engaging in “Harvest Now, Decrypt Later” (HNDL) attacks. This involves recording and storing large volumes of today’s encrypted data. While it can’t be decrypted now, it will be possible to retroactively decrypt it all once a capable quantum computer becomes available.

The threat to authenticity - the function of digital signatures - is different but equally severe. This scenario can be described as “Harvest Now, Break Later, Forge Forever” (HNBLFF):

• Harvest Now: An attacker records a target’s public key. This isn’t a secret; a module-signing key, for example, is public by design.
• Break Later: On or after Q-Day, the attacker uses Shor’s algorithm on a quantum computer to derive the corresponding private key.
• Forge Forever: Once this private key is compromised, the attacker can use it to sign their own malicious code - such as rootkits or spyware.
• The Attack: The attacker’s malicious module is loaded onto a target system. The kernel, which is correctly configured to enforce module signing, checks the signature.
• Compromise: The signature is cryptographically valid and authentic. The kernel, trusting the signature, loads the malicious code directly into Ring 0.

This patch, therefore, is a foundational defense mechanism to protect the kernel’s entire chain of trust.

The most immediate and unavoidable impact of ML-DSA is the “size tax.” Its public keys and signatures are significantly larger than their RSA and ECC counterparts. A single kernel module signed with ML-DSA-65 will have a signature of 3,309 bytes, replacing a 384-byte RSA signature.

This has a direct impact on the initramfs (or initrd), the initial RAM disk that contains all the critical drivers necessary to boot the system. An initramfs with dozens of modules will see a non-trivial increase in size, which in turn increases I/O load and boot times. For resource-constrained embedded systems, this added size could be a significant challenge.

Implementation Challenges

Merging the code’s only the first step. The actual difficulty of the PQC migration lies in the surrounding tools, standards, and hardware, which is still immature and, in some cases, in conflict.

Challenge 1: Toolchain Incompatibility with OpenSSL

The kernel’s sign-file utility, used to sign modules, relies on the OpenSSL library and its Cryptographic Message Syntax (CMS) implementation. This has exposed a critical incompatibility.

The Problem: The ML-DSA algorithm is designed to perform its own internal hashing on the message. However, the existing CMS standard (and OpenSSL’s implementation) is intended for algorithms like RSA, which sign an external hash of the data, accompanied by metadata called authenticatedAttributes.

The Conflict: OpenSSL’s ML-DSA implementation for CMS didn’t permit opting out of these attributes.

The Workaround: David Howells’ patch series modifies the kernel’s PKCS#7 parser to accept these attributes. Still, it then passes the full attribute blob directly to the ML-DSA verifier, which then performs the internal hashing it expected to do all along. This is a necessary “glue code” solution to bridge the gap between the new algorithm and the legacy standard.

Challenge 2: The Private Key Format Schism (The 32-Byte Seed)

A more significant issue is emerging from a disagreement between standards bodies over the correct format for an ML-DSA private key. NIST FIPS 204: The official standard from NIST allows for two different, but related, representations of a private key:

• A 32-byte “seed”
• The “expanded private key” (a multi-kilobyte structure generated from the seed).

IETF Standards: The Internet Engineering Task Force (IETF), which defines how these keys are used in protocols like X.509 certificates, is standardizing on a “seed-only” format for private keys. RFC 9881 recommends this format.

The Trap: The conversion from the 32-byte seed to the expanded key is a one-way function. It’s impossible to recover the original seed from the expanded key.

This schism creates a critical problem for key management, especially for Hardware Security Modules (HSMs): Imagine that an administrator uses an HSM to generate a new private key for PQC signing. The HSM, following FIPS guidance that internal functions should not be exposed, generates the key, stores the “expanded private key,” and discards the 32-byte seed as a security best practice.

The administrator makes an encrypted backup of this “expanded private key.”

The HSM hardware fails.

The administrator purchases a new HSM or tries to import the key into a new software tool (like OpenSSL). This new tool, following the IETF standard, only accepts the 32-byte seed format for key import; however, the seed wasn’t retained.

The backup is now useless. The expanded key can’t be converted back to the seed. The private key and its entire chain of trust are permanently lost.

A Pragmatic Path Forward: Audit and Plan

The introduction of ML-DSA support in the kernel shows that the post-quantum migration is transitioning from a theoretical discussion to practical implementation.

While this transition is a long-term process that will span years, the HNDL and HNBLFF threats and the complex implementation challenges mean that it’s good to begin planning.

The primary action is to establish a crypto inventory. This means identifying every system and process that relies on a classical public key for authenticity. This includes kernel module signing, Secure Boot Machine Owner Keys (MOKs), SSH keys, and others.

As new hardware (such as HSMs) is procured, vendors must be asked pointed questions to ensure a thorough evaluation. Specifically, “Does this device support FIPS 204 ML-DSA, and does it provide a standards-compliant method to back up and restore the 32-byte private key seed?” An inability to answer this question is a significant red flag.

The kernel patch provides the necessary software foundation, but the true challenge will be navigating the complex and unavoidable hardware and tooling transition that lies ahead.