QuantaCipher audit: advertised ML-KEM, shipped Kyber

Read a post-quantum datasheet and you will be told which standard the product implements. It is the one claim a buyer cannot check without unpacking the binary, and it is the claim most likely to be out of date, because the standards moved and the code did not.

QuantaCipher advertised NIST ML-KEM and FIPS 203. What it shipped was the pre-standard round-3 Kyber submission, at the 768 parameter set, while the marketing described NIST Level 5. Two things were true at once: the algorithm was not the standardised one, and the delivered security level was Level 3 rather than the Level 5 on the page.

What was sound

Starting here is not politeness, it is the finding that took the longest to establish. We found no data-exposure path, and the construction is built correctly.

• Correct CSPRNG throughout. KEM keygen and encapsulation use OsRng, nonces use the AEAD's OsRng, and in WASM that resolves to Web Crypto getRandomValues. No weak randomness anywhere.
• A sound KEM/DEM construction: AES-256-GCM, a fresh 96-bit random nonce per operation, and a fresh KEM shared secret per message, so key reuse and nonce reuse are structurally impossible rather than merely avoided.
• The local-only claim substantially holds. The encryption path does not phone home.

That matters for how the rest of this reads. A product with a broken construction and an accurate datasheet is in worse shape than this one. The defects here are in what the product says about itself.

The label the runtime returned

Alongside the mismatch, the runtime reported its algorithm as a hardcoded constant rather than deriving it from the implementation in use.

This is a small defect with a long tail. Downstream policy engines, CBOM generators and attestation tooling record whatever the runtime tells them. A constant string means those records are wrong wherever the constant is wrong, and they are wrong silently, in someone else's compliance evidence, months later. An inventory built from that output describes a deployment that does not exist.

One migration, three findings

The KEM came from pqc_kyber, an unmaintained crate carrying the KyberSlash advisory: a timing side channel in the key-recovery class, CVSS 7.4. Exploitability in a local-only usage model is low, since an attacker has to be positioned to measure decapsulation. Shipping an unmaintained crate with an unfixed advisory is the problem regardless of the day's exploitability, because nobody is going to fix the next one either.

So the highest-leverage recommendation was a single line of work: migrate to the maintained ml-kem crate at the 1024 parameter set. That makes the FIPS 203 claim true, closes the parameter-set discrepancy, and removes the advisory. Three findings collapse into one migration. Whether the claim holds afterwards is a conformance question, which is why we measured instead of taking the report.

We measured the fix

They made the migration. We did not take it on report.

The published WASM build now returns a public key of 1568 bytes and a secret key of 3168 bytes. Those are the FIPS 203 ML-KEM-1024 sizes, and they are not the Kyber-768 sizes the previous build produced, so the byte counts alone settle both the algorithm question and the parameter-set question. The runtime now reports an algorithm string that agrees with them. The core's dependency manifest no longer carries pqc_kyber. The SDK's default gateway resolves, and refuses plain HTTP outside localhost.

All six fixed. The original four fixes are linked to quantacipher-core 0.3.5, quantacipher-wasm 0.4.4 and quantacipher-sdk 1.4.3. On 12 September 2026 we also verified source and build provenance for the scoped SDK and WASM 2.0.6 packages.

Source provenance and gateway metadata remediated

The source-provenance finding is now closed for the checked 2.0.6 artifacts. The gateway-metadata finding is also closed for SDK 2.0.6, which omits caller-supplied metadata from its requests.

The official source repository is public. We extracted the JavaScript entry point and WASM binary from the scoped 2.0.6 npm packages and verified their GitHub build attestations against the v2.0.6 release workflow. Both attestations identify commit 88fcab36615f7a368ef291d0355541f90af0b7b2. This verifies build origin for those files; it does not establish reproducible builds or verify older releases. The SDK still declares a wildcard WASM dependency, so consumers should pin the installed version and keep a lockfile.

On 16 September 2026 we rechecked the published scoped SDK 2.0.6 and its gateway request construction. The request body contains only ciphertext and a timestamp. With WASM and HTTP transport mocked, all three gateway paths omitted supplied userId and record-type metadata. The argument is ignored, not encrypted or retained, so sensitive context that must survive belongs inside the encrypted payload. The gateway still sees API-key identity, timing and network information. This closes the specific metadata-disclosure finding without claiming traffic anonymity or extending verification to older SDKs or Python bindings.

The point

The gap between what a product says and what it ships is not usually dishonesty. It is a standard that changed under a codebase, a datasheet written once, and a version string typed as a constant because at the time it was true. The result is the same for the buyer either way: a compliance claim that fails the first time anyone checks it.

Which is why we publish the byte sizes. A number a reader can reproduce against the published artifact outlives any grade we could put on the page, and it is the only form of this claim that stays true without us.

References

• The full review at quantakrypto.com, with every finding and its status
• FIPS 203 at csrc.nist.gov
• KyberSlash at kyberslash.cr.yp.to
• quantacipher-core 0.3.5 on crates.io

If your product claims a standard, the cheapest way to find out whether it still ships one is to have someone measure it. That is what an audit is. Talk to us.