Ledger adds post-quantum algorithms to its SDK

Ledger adds two post-quantum building blocks

Ledger added ML-KEM and ML-DSA cryptographic implementations to its software development kit (SDK). The release concerns building blocks that applications can use. It does not announce that every supported blockchain has changed its transaction signatures. Ledger also explicitly says this first implementation lacks hardware countermeasures against side-channel and fault-injection attacks. These attacks observe physical signals from a chip or deliberately disturb its operation. That limitation belongs alongside the announcement, not in a footnote that disappears behind the term “post-quantum.”

The two algorithms solve different problems

NIST’s FIPS 203 defines ML-KEM as a way for two parties to establish a shared secret over a public channel. That secret can then be used by other cryptographic algorithms for tasks such as encryption and authentication. ML-KEM is therefore part of setting up protected communication, rather than a replacement name for every operation performed by a wallet. The standard offers three parameter sets with different security and performance trade-offs.

What a digital signature adds

NIST’s FIPS 204 defines ML-DSA for creating and checking digital signatures. Signatures help a recipient detect changes to data and authenticate the signer. The standard describes the algorithm as believed secure even against an adversary with a large-scale quantum computer. That is a carefully bounded security claim about the scheme, not a statement that any product containing its code is invulnerable.

The distinction is useful for reading this release. Establishing a secret and verifying a signature are related security tasks, but an application chooses and connects the components it actually needs. A standards-based algorithm still sits inside a wider implementation and operating environment.

An illustrative path from library to usable product

Imagine a developer building a fictional document-approval tool. Adding a signature routine to a library is one step. The tool still needs to decide exactly which document is signed, how that document is represented, where the verification key comes from and what the recipient sees if verification fails. A working demonstration must connect all of those decisions.

Suppose the developer signs one version of a document but displays a different summary to the person approving it. Correct signature mathematics would not make the misleading presentation acceptable. Conversely, a clear interface would not compensate for a broken verification step. This example shows why evaluating the whole workflow requires more than recognising a familiar algorithm name.

For a wallet application, the same style of review asks whether the intended transaction, the information presented to the user and the data checked by the receiving system agree. This is an editorial test model. It is not a claim that Ledger has released the fictional application or that a particular blockchain already accepts these signatures.

How to read performance and security claims together

A developer evaluating a new implementation can create a concrete comparison using the same operation, target device and test conditions. Useful observations include whether the operation completes, how long it takes, how much memory it needs and what happens on invalid input. Recording the conditions matters because an isolated “fast” or “small” result says little about another application’s workload.

For instance, a reviewer could alter one character in the fictional document and confirm that its original signature no longer validates against the altered text. They could then repeat the test with the unmodified document. Keeping both outcomes prevents a failed test harness from being mistaken for successful tamper detection.

Security evaluation also needs a stated adversary. A system tested against malformed messages has not necessarily been evaluated against someone physically manipulating its hardware. A product team should identify which question each test answers and which question remains open. That is particularly relevant when a release itself names a physical-attack limitation.

For an ordinary wallet owner, the useful follow-up is a product-specific explanation of what has actually changed. Look for the supported action, relevant software version and any required migration procedure. The presence of a new SDK primitive alone does not tell a user to move assets, replace a device or regard existing holdings as newly protected by a different blockchain signature system. The substantive news is that developers have another implementation to evaluate, with an explicit boundary around its first version.