ML-KEM and the Future of Code Signing in a PQC World 

Introduction 

We’ve relied on algorithms like RSA and ECC for years to protect everything from emails to software updates. They’ve held up pretty well as long as attackers don’t have a quantum computer. But that’s the problem: quantum computing is no longer just a theoretical idea. It’s progressing fast enough that cryptographers are seriously thinking about what happens when these machines become practical. 

Quantum computers break things in a very specific way. They don’t just make our systems faster; they make some cryptographic problems trivial, like factoring large numbers (which breaks RSA) or solving the discrete log problem (which breaks ECC). That means if we continue using current algorithms, anything encrypted or signed today could be cracked in the future, once a quantum computer catches up. 

This is where post-quantum cryptography steps in. It’s not about fixing broken systems, it’s about future-proofing them. We need new algorithms that stay safe even if quantum computers become a reality. That’s exactly the problem ML-KEM is built to solve. 

Overview of ML-KEM  

ML-KEM stands for Module-Lattice Key Encapsulation Mechanism, and it’s part of the new set of cryptographic algorithms selected by NIST to help protect against quantum threats. You might’ve heard of Kyber ML-KEM, which is basically Kyber with a formal name as it moves toward standardization. 

At its core, ML-KEM helps two systems establish a shared secret over an insecure connection. It’s like Diffie-Hellman or RSA-based key exchange, but built to resist quantum attacks. That makes it a perfect fit for securing communication between apps, systems, and even hardware like HSMs, especially in sensitive workflows like code signing. 

Why does this matter now? Because many software vendors, certificate authorities, and security tools are already thinking ahead. If you’re building systems that will be used 5 or 10 years from now, you can’t ignore the quantum angle anymore. ML-KEM helps ensure that your key exchange mechanisms won’t become tomorrow’s weakest link. 

What is ML-KEM? 

Origins of ML-KEM from Kyber 

ML-KEM didn’t just pop out of nowhere. It’s actually the formal name for a tried-and-tested algorithm called Kyber, which has been around for a while in post-quantum cryptography circles. When NIST (National Institute of Standards and Technology) ran a global competition to choose new cryptographic standards that can stand up to quantum attacks, Kyber stood out. 

After years of testing, discussions, and security evaluations, NIST gave it the green light in 2022 as its go-to algorithm for key exchange in a quantum-safe world. As part of finalizing the standard, Kyber was renamed ML-KEM, which stands for Module-Lattice based Key Encapsulation Mechanism. Think of it as the official version of Kyber that’s now being adopted in real-world systems. 

ML-KEM’s Job: A Quantum-Safe KEM 

So, what does ML-KEM actually do? It’s a Key Encapsulation Mechanism or KEM for short. In simple terms, it’s used to securely exchange a shared secret key between two parties over an insecure connection. This is the key step in many cryptographic systems: you and someone else need to agree on a secret that no one else can see, even if they’re watching everything you send. 

Traditionally, we’ve used algorithms like RSA and Elliptic Curve Diffie-Hellman for this. But those won’t survive a quantum attack. ML-KEM steps in as a replacement—it lets you encapsulate (or “wrap”) a shared secret in a way that’s safe even if someone has access to a future quantum computer. 

And just like traditional KEMs, once the shared secret is exchanged, it can be used for symmetric encryption, like AES, to protect data or sign software packages in transit.

Why ML-KEM Works: The MLWE Problem 

Under the hood, ML-KEM is built on something called the Module Learning With Errors problem, or MLWE for short. This sounds complicated, but here’s the gist: 

Imagine trying to solve a simple math problem where someone has deliberately added a bit of noise to the answer. You might still get close, but cracking it perfectly, especially across many dimensions, is incredibly hard. That’s the essence of MLWE: it’s based on math problems that are easy to compute one way but painfully hard to reverse, especially when noise is thrown in. 

This kind of math holds up even when a quantum computer gets involved. That’s why MLWE-based algorithms like ML-KEM are considered safe bets for the future. It’s not just theory; this problem has been analyzed for years, and no one’s found a practical way to break it with either classical or quantum methods. 

How ML-KEM Works 

Let’s break it down into what actually happens when you use ML-KEM to securely exchange a key. It’s fast, efficient, and works kind of like a secure digital handshake with some serious math behind the scenes. 

Key Generation 

First up: key generation. This is where one party (let’s say, a server) creates a public key and a private key. The public key is shared with others, and the private key is kept safe and never leaves the system. 

Think of it like this: 

• Public key: A lock you hand out to anyone who wants to send you a secret. 
• Private key: The key that opens the lock and lets you read that secret. 

In ML-KEM, these keys are based on lattice math (specifically the MLWE problem), which makes them strong against attacks from quantum computers. 

Encapsulation and Decapsulation 

Now comes the encapsulation part. 

Suppose a client wants to send a shared secret to the server. Here’s what happens: 

• The client uses the server’s public key to create a ciphertext (a scrambled message). 
• Along with the ciphertext, the client also generates a shared secret key. 
• The ciphertext gets sent over to the server. 

Then comes decapsulation: 

• The server uses its private key to decrypt the ciphertext. 
• It gets the same shared secret key that the client generated. 

Now, both sides have the exact same secret, without actually sending the key over the network. Even if someone’s eavesdropping, they can’t figure out the secret, because they’d need the private key, and solving the math problem without it is practically impossible (even for quantum machines). 

Security Levels: ML-KEM-512, 768, 1024

ML-KEM comes in three levels, each offering a different level of security: 

• ML-KEM-512: Recommended for most use cases, roughly equivalent to 128-bit classical security. 
• ML-KEM-768: A step up, offering about 192-bit security. 
• ML-KEM-1024: Highest level, with 256-bit security, ideal if you’re securing stuff that really can’t be risked. 

Each level increases the size of the keys and ciphertexts a bit, but also increases the difficulty for attackers trying to break the encryption. In short: pick the level that fits your risk profile and performance needs. 

Resistance to Quantum Attacks 

So, how is ML-KEM “quantum-safe”? Here’s the simple idea: ML-KEM is based on lattice problems that are hard to solve even for quantum computers. Algorithms like Shor’s (which breaks RSA and ECC) don’t help much here. And despite years of cryptanalysis, no one’s figured out how to break MLWE-based systems efficiently with quantum techniques. 

In fact, one of the reasons Kyber (now ML-KEM) was selected by NIST is because it struck a solid balance between performance and quantum resistance. It’s fast enough for practical use, yet backed by solid math that makes quantum attacks a no-go. 

ML-KEM in the NIST PQC Standardization Process 

NIST’s Role in Post-Quantum Standardization 

The National Institute of Standards and Technology (NIST) isn’t just another acronym in cryptography; they’re basically the referees. When it comes to what encryption gets used in government, critical infrastructure, and major industry systems, NIST decides what’s safe and what’s outdated. 

Back in 2016, NIST kicked off a global competition to find cryptographic algorithms that could stand up to quantum computers. The idea was simple: let researchers submit their best ideas, throw every known attack at them, and see what survives. 

Out of 80+ submissions, only a few made it to the finish line. One of them was Kyber, which now carries the name ML-KEM as part of the official standard. 

Why Kyber (ML-KEM) Was Chosen 

So why did Kyber beat the competition? 

Here’s what made it stand out: 

• Strong security foundation: Based on the Module Learning With Errors (MLWE) problem, which is widely trusted in the crypto world. 
• Efficient performance: It’s fast and doesn’t need huge keys or ciphertexts. Great for real-world systems, including low-power devices. 
• Clean design: Unlike some other candidates, Kyber had a straightforward, well-documented implementation that made auditing and integration easier. 
• Broad support: It gained popularity in early prototypes and open-source libraries like OpenQuantumSafe, so it already had momentum. 

The result? NIST selected Kyber for standardization and renamed it ML-KEM in 2022. That makes it the official post-quantum KEM of the future. 

ML-KEM vs Traditional Key Exchange Algorithms (RSA/ECC) 

Let’s be honest, RSA and ECC have done their job pretty well over the years. They’re behind the scenes in your HTTPS connections, secure email, VPNs, and yes, even code signing. But with quantum computing getting closer, it’s time to look at what happens when we compare those classics to ML-KEM, the post-quantum alternative.

Performance 

When it comes to speed, ML-KEM actually holds up surprisingly well. 

• RSA gets slower as you increase key sizes (which you must do for better security). 
• ECC is faster than RSA but not designed to handle quantum resistance. 
• ML-KEM is designed for performance with security in mind. It’s fast at both key generation and encapsulation/decapsulation, even faster than RSA in many cases. 

For real-world use cases like TLS or code signing infrastructure, this makes ML-KEM a serious upgrade, not just a fallback. 

Key Sizes 

Here’s where the numbers get interesting: 

Algorithm	Public Key Size	Ciphertext Size	Security Level
RSA-2048	~256 bytes	~256 bytes	~112-bit
ECC (P-256)	~64 bytes	~64 bytes	~128-bit
ML-KEM-512	~800 bytes	~768 bytes	128-bit PQ
ML-KEM-768	~1200 bytes	~1088 bytes	192-bit PQ

Yes, ML-KEM keys and ciphertexts are larger than ECC and RSA, but they’re still small enough to work efficiently in most systems. They’re also far smaller than some other post-quantum algorithms that NIST didn’t select. 

Security Assumptions 

• RSA relies on the difficulty of factoring large numbers. 
• ECC depends on solving the elliptic curve discrete log problem. 
• Both of those get wrecked by quantum computers using Shor’s algorithm. 

ML-KEM, on the other hand, is based on lattice problems, specifically MLWE. These aren’t just resistant to known quantum attacks; they’ve been studied for years with no major cracks. That’s why ML-KEM is considered safe even in the future when working with quantum machines. 

So, if you want your system to be secure in 10–15 years, ML-KEM is the smarter bet. 

Impact on Resource-Constrained Environments 

You’d think larger keys would make ML-KEM hard to use on tiny devices, but it’s actually surprisingly efficient. 

• Unlike some PQ algorithms that need lots of memory or CPU, ML-KEM keeps things lean. 
• It’s been tested on everything from cloud servers to microcontrollers, and it performs well across the board. 
• Many TLS and VPN prototypes already run with ML-KEM just fine on mobile phones and embedded chips. 

Sure, if you’re trying to run cryptography on a sensor running off a coin cell battery, you’ll need to test carefully. But in most real-world cases, ML-KEM is fast and light enough to get the job done even where ECC used to shine. 

The Role of ML-KEM in Code Signing 

How Code Signing Works 

Code signing is how software publishers prove that their app or update hasn’t been tampered with. Here’s the basic flow: 

• The publisher hashes the code (to create a digital fingerprint). 
• That hash is signed with a private key. 
• When users or systems receive the software, they verify the signature using the matching public key, usually stored in a certificate. 

If the signature checks out, the code is trusted. If not, it’s flagged. Simple enough, but the whole process depends on public key crypto, usually RSA or ECC, to make it trustworthy. 

What’s the Problem? Quantum Breaks It  

Traditional code signing uses algorithms like RSA and ECC, which are fine until a quantum computer enters the picture. 

• Quantum computers can crack RSA and ECC using Shor’s algorithm. 
• That means attackers could one day forge signatures, and your system would have no idea it’s been tricked. 

Even if quantum computers aren’t here yet, attackers could harvest signed code and certificates now and break them later. That’s a big problem for long-lived code (like firmware or OS updates) or anything stored offline. 

Why ML-KEM Matters for Signing Systems 

ML-KEM doesn’t replace digital signatures, but it plays a key supporting role, especially in systems where: 

• Signing is done over a network 
• Secrets need to be exchanged securely 
• You want to move toward post-quantum readiness without dropping support for today’s clients 

Here’s where ML-KEM fits in: it gives you a quantum-safe way to exchange encryption keys between systems that need to coordinate around code signing. That’s especially helpful in hybrid crypto models, where you combine traditional signing algorithms with post-quantum components. 

Think of ML-KEM as the secure handshake behind the scenes that keeps keys, credentials, and signing commands safe even if someone is watching. 

How ML-KEM Fits into the Signing Workflow  

• Certificate Provisioning

  When you’re requesting a code signing certificate from a CA, ML-KEM can be used to: 

  1. Encrypt private keys or challenge responses during provisioning.
  2. Make the entire exchange quantum-safe, so attackers can’t intercept or replay it years later.
  3. Combine with traditional key pairs in hybrid certificate requests, where both RSA/ECC and post-quantum credentials are included.
• Signing Server to Client Communication

  A lot of companies use a remote signing server (or HSMs) that handle private keys. ML-KEM can be used to: 

  1. Set up a secure channel between the client and the signing service.
  2. Protect API tokens, key handles, or command payloads from interception even by future quantum attackers.
  3. Avoid reliance on RSA-based TLS by supporting quantum-safe key exchange.
• Secure Software Delivery Pipelines

  In automated CI/CD setups, secrets often pass between tools, containers, or cloud services. ML-KEM can help: 

  1. Encrypt ephemeral keys or signing instructions between pipeline steps.
  2. Ensure build agents or signers aren’t exposed, even if the pipeline is public-facing.
  3. Lay the foundation for quantum-resilient build processes, where both transport and signing hold up against future threats.

Integrating ML-KEM into Our CodeSign Secure

If you’re building or maintaining secure software pipelines, our CodeSign Secure is designed to make code signing smarter, more automated, and future-proof. And with ML-KEM now standardized by NIST, it’s time to bring post-quantum protection into the picture,  without throwing out everything that already works. 

Real-World Integration with Tools (OpenSSL, PQCrypto Libraries) 

You don’t need to reinvent everything to start using ML-KEM. Thanks to active open-source work and early adoption, you can already plug it into many familiar tools: 

• OpenSSL (via forks like [OpenQuantumSafe’s liboqs]) supports ML-KEM for key exchange. 
• Libraries like PQClean, liboqs, and PQCrypto have clean, production-ready implementations. 
• Our CodeSign Secure builds on this by offering ML-KEM-based secure channels between the signing client and the signing backend, using these battle-tested libraries under the hood. 

In short, we bring ML-KEM into your stack without asking you to rip out OpenSSL or abandon your automation scripts. 

Hybrid Schemes (ML-KEM + RSA/ECDSA) 

Let’s be realistic: most ecosystems still rely on RSA or ECDSA for digital signatures, especially when compatibility matters (Windows Authenticode, Apple Notarization, etc.). 

So instead of going all-in on post-quantum crypto right away, our platform supports hybrid schemes, where we combine: 

• RSA/ECDSA for signatures. 
• ML-KEM for key exchange and session encryption. 

This way, even if the signature is made with a classic algorithm, the private key stays protected using a post-quantum channel. It’s a smart way to transition while keeping everything compatible with existing trust models and toolchains. 

HSM and PKCS#11 Support 

Our platform already supports PKCS#11 for interacting with HSMs, and we’re extending this to support post-quantum key exchanges and hybrid signing too. 

• ML-KEM keys can be stored and managed using the vendor-specific extensions or embedded alongside traditional keys. 
• We support signing workflows where the session is protected using ML-KEM, and the signature is performed using a PKCS#11-backed private key (like RSA-3072 or ECDSA-P384). 

It’s fully compatible with Thales, nShield, and other leading HSMs, and we’re working with vendors to expand native support for ML-KEM keys under PKCS#11. 

Challenges and Considerations 

Switching to post-quantum crypto like ML-KEM isn’t just flipping a switch. It’s a move with some trade-offs and a few things to think through, especially if you’re working with code signing systems that need to stay reliable, fast, and compatible. 

Performance vs. Security Trade-offs

ML-KEM is fast for a post-quantum algorithm, but it’s not as lightweight as ECC or RSA when it comes to key and ciphertext sizes. 

• For example, ML-KEM-512 public keys are around 800 bytes, and ciphertexts are similar, much bigger than ECC, but still manageable. 
• If you go for higher security levels (like ML-KEM-768 or -1024), expect even larger keys and more CPU usage during encapsulation and decapsulation. 

So, if you’re using ML-KEM in something like CI/CD pipelines or embedded systems, you’ll need to balance security needs with how much overhead your system can handle. In most modern server setups, it’s barely noticeable, but it’s something to test. 

Interoperability with Legacy Systems 

Here’s the sticky part: a lot of tools, protocols, and platforms don’t know what to do with post-quantum algorithms. 

• Most operating systems, browsers, and mobile platforms still expect RSA or ECDSA keys in certificates. 
• Build tools, CI/CD platforms, and package managers aren’t yet ready for full PQ crypto. 

That’s why hybrid schemes matter. You can layer ML-KEM into the handshake or transport, while still using RSA or ECC where compatibility is critical. It’s a way to move forward without breaking existing stuff. 

Secure Storage and Protection of ML-KEM Keys 

ML-KEM keys, like any private key, need to be stored securely and managed carefully. But there are some quirks to deal with: 

• Not all HSMs or key stores support ML-KEM yet. 
• Some PKCS#11 modules may need vendor-specific extensions to hold ML-KEM key objects. 
• If you’re doing software-based key storage (not ideal), you’ll need strong OS-level protections, encryption, and access control. 

In our platform, we’re working on HSM-backed and encrypted container-based storage for ML-KEM key material, along with support for exporting keys in formats like [NIST’s SP 800-56Cr1] so you can keep things clean and auditable. 

Conclusion 

ML-KEM isn’t just a theoretical upgrade; it’s the key to keeping your signing systems secure in a world where quantum computing is no longer science fiction. As NIST’s top pick for post-quantum key exchange, ML-KEM is already shaping how modern cryptographic systems are being built, especially for use cases like code signing where long-term security is critical. Whether you’re signing firmware, distributing software updates, or managing CI/CD pipelines, it’s smart to assume that someone out there could be storing your signed code today to break it tomorrow. ML-KEM helps shut that door. 

You don’t need to tear down your existing systems to start preparing. With hybrid models, ML-KEM can work right alongside RSA or ECDSA, securing the handshake and session while leaving the signature algorithm untouched for now. This makes it easy to add quantum-resistant protection to your code signing workflow without breaking compatibility with the tools and platforms you’re already using. Even adding ML-KEM to your signing server communications or certificate provisioning process makes a huge difference in future-proofing your pipeline. 

Quantum attacks might not be here today, but they’re coming, and attackers are playing the long game. That’s why adopting post-quantum crypto early gives you a serious edge. Starting with secure key exchange is a practical first step, and ML-KEM is ready for it. You can layer it into your systems today and scale up over time as industry support grows. 

If you’re looking to make this shift without the headache, our code signing platform, CodeSign Secure, is designed to help. Our platform supports ML-KEM for secure key exchange, works with HSMs via PKCS#11, and lets you run hybrid signing schemes without changing how your teams build and release software. Whether you’re modernizing your signing infrastructure or just getting started, our platform gives you the tools to stay ahead without compromising compatibility or security.