kxco-post-quantum 1.5.1 → 1.5.3

package/BENCHMARKS.md

@@ -85,15 +85,19 @@ Milliseconds. 100 iterations except where the `n` column says otherwise.
 
 **Two numbers to design around.**
 
-**ML-DSA signing has a long tail.** ML-DSA-65 signs in 11 ms at the median and
-51 ms at p99, a factor of 4.5. Rejection sampling means an unlucky signature does
-several more rounds. Size request budgets from p99, not the median.
-
-**SLH-DSA-SHA2-192s signs in about 6.8 seconds.** That is the set `slhDsa` wraps,
-and it is not a per-request operation. It suits infrequent, high-value signatures
-such as firmware or root attestations. Verification is cheap, around 5 ms, so an
-SLH-DSA signature is expensive to make and cheap to check. The `f` variants trade
-signature size for signing speed: SHA2-128f signs in 151 ms.
+**ML-DSA signing has a long tail, on both backends.** ML-DSA-65 signs in 8.1 ms
+at the median and 40.8 ms at p99 in JavaScript, a factor of 5.1. On OpenSSL it is
+1.3 ms and 4.6 ms, a factor of 3.5. Rejection sampling means an unlucky signature
+does several more rounds, and no backend removes that. Size request budgets from
+p99, not the median, and from the p99 of the backend you will actually run.
+
+**SLH-DSA-SHA2-192s signs in seconds, not milliseconds:** about 4.3 s in
+JavaScript and 1.7 s on OpenSSL. That is the set `slhDsa` wraps, and on either
+backend it is not a per-request operation. It suits infrequent, high-value
+signatures such as firmware or root attestations. Verification is cheap, 7.5 ms
+and 1.3 ms respectively, so an SLH-DSA signature is expensive to make and cheap
+to check. The `f` variants trade signature size for signing speed: SHA2-128f
+signs in 98 ms in JavaScript and 69 ms on OpenSSL.
 
 ## Key encapsulation
 
@@ -155,11 +159,12 @@ collection timing, not evidence that the larger parameter set allocates less.
 
 - **One machine, one run.** Node v26.1.0 on win32-x64. Absolute numbers move with
   hardware and runtime; the ratios between operations are the portable part.
-- **Not a cross-vendor comparison.** Nothing here was measured against another
-  implementation, so it says nothing about how this compares to a native or
-  hardware-backed stack. It will be slower than both.
+- **Not a cross-vendor comparison.** The two backends here are both ours to
+  ship, so the comparison above is between two paths through this package, not
+  between this package and someone else's. It says nothing about how either
+  compares to a hardware-backed stack.
 - **Reduced samples where marked.** SLH-DSA slow variants take 3 to 20 samples
-  rather than 100, because 100 signatures at 6.8 seconds each is not a benchmark,
+  rather than 100, because 100 signatures at seconds each is not a benchmark,
   it is an afternoon. Where n is small, p95 and p99 collapse onto the maximum and
   are reported that way rather than dressed up.
 - **Not a side-channel measurement.** Timing here is throughput, gathered without

package/CHANGELOG.md

@@ -1,5 +1,65 @@
 # Changelog
 
+## 1.5.3
+
+Documentation and metadata. No code change.
+
+Corrects stale performance figures. The README and BENCHMARKS.md both quoted a
+4.5x median-to-p99 tail for ML-DSA signing and about 6.8 seconds for
+SLH-DSA-SHA2-192s. Measured now, across both backends: the tail is 5.1x in
+JavaScript and 3.5x on OpenSSL, and SLH-DSA-SHA2-192s signs in 4.3 s and 1.7 s.
+
+Says what the package does. The README still described it as a wrapper around
+@noble/post-quantum without mentioning that on Node 24 and later the primitives
+run in OpenSSL 3.5. The npm description, which is what appears in registry search
+results, listed the algorithms and nothing else: not the 2,103 NIST ACVP vectors,
+not the 225-check interoperability matrix, not the reproducible build or the
+provenance attestation. Those are the parts that distinguish this from any other
+post-quantum wrapper, and they were absent from the one line most readers see.
+
+A dependabot ignore blocks @noble/post-quantum 0.7.1 specifically, so it is not
+reproposed weekly. The ACVP job fails the build on it regardless; this stops the
+pull request being opened. 0.7.2 and later will still be offered and should be
+accepted once the vectors pass.
+
+## 1.5.2
+
+**Reverts `@noble/post-quantum` to 0.7.0. Upgrade from 1.5.1 immediately if you
+verify SLH-DSA signatures.**
+
+1.5.1 bumped the backend to 0.7.1. That version **fails nine NIST ACVP SLH-DSA
+verification vectors that 0.7.0 passes**, returning `false` where the vectors
+require `true`. In practice that means a valid SLH-DSA signature can be
+rejected. It is a correctness and availability fault, not a security weakening:
+nothing invalid is accepted. No other algorithm family is affected, and ML-DSA
+and ML-KEM pass unchanged on both versions.
+
+The failures are confined to the **internal** signature interface
+(`SLH-DSA.Verify_internal`), not the pre-hash interface, and appear across both
+SHA2 and SHAKE parameter sets: SHA2-128s, SHA2-192f, SHA2-256f, SHA2-256s,
+SHAKE-128f, SHAKE-128s, SHAKE-256f, SHAKE-256s. Reproduce with:
+
+```
+npm run conformance:fetch
+node conformance/run-acvp.mjs --set SLH-DSA-sigVer-FIPS205 --max-per-group 3
+```
+
+0.7.0 returns 87 passed, 0 failed, 21 skipped. 0.7.1 returns 78 passed, 9
+failed.
+
+This has been reported upstream. Until it is resolved the pin stays at 0.7.0,
+and the ACVP job will fail the build on any attempt to move it, which is the
+behaviour we want.
+
+**Why this is worth saying plainly rather than quietly reverting.** The
+conformance evidence in this repository is not decoration. It caught a real
+regression in a dependency within hours of that dependency's release, on a
+version bump whose own release notes described only hardening. A test suite that
+passes is not evidence; a test suite that fails when something breaks is. Ours
+did.
+
+1.5.1 is deprecated on npm.
+
 ## 1.5.1
 
 Dependency bump: `@noble/post-quantum` 0.7.0 to **0.7.1**, published 2026-08-27.

package/CONFORMANCE.md

@@ -187,6 +187,62 @@ Everything else is exercised against liboqs, in both directions, including FIPS
 
 ---
 
+## 3. Edge cases
+
+Passing vectors in the middle of the range says nothing about the ends. These are
+run by `npm test` on every supported runtime, so they cover both backends:
+OpenSSL on Node 24 and later, JavaScript on Node 20 and 22.
+
+| Case | Asserted |
+|---|---|
+| Zero-length message | signs and verifies, and does **not** verify against a one-byte message |
+| Empty vs absent context | both verify, and normalise identically |
+| Context of exactly 255 bytes | accepted; one flipped byte in it fails verification |
+| Context of 256 bytes | **throws**, rather than returning false |
+| Malformed signature | empty, odd-length hex, non-hex, one byte short, one byte long, all zeroes, all ones: all return false, none throw |
+| Wrong-size public key | empty, short, long, all zeroes: all return false, none throw |
+| Signature under another key | false |
+| One-megabyte message | verifies, and a flip in the **final** byte is detected |
+| Corrupted ML-KEM ciphertext | returns an unrelated secret of the correct length, not an error |
+| Repeated encapsulation | ciphertext and secret both differ |
+| Key derivation | deterministic from the same master, different for a different info string |
+
+Two of those deserve their reasoning stated, because the behaviour is a choice:
+
+**A cryptographic failure returns false; caller misuse throws.** A wrong key or a
+corrupted signature answers the question "is this valid" with no, and no is a
+value. A 256-byte context is a bug in the calling code, and returning false there
+would let a program that can never verify anything look like a program that is
+merely receiving bad signatures.
+
+**The one-megabyte case is not a size limit test.** It flips the last byte and
+requires that verification fails. An implementation that hashed only a prefix
+would pass every other case in this suite.
+
+## 4. Object identifiers
+
+The NIST OIDs each parameter set is published under. These are not transcribed
+from a registry: they are read back out of the SubjectPublicKeyInfo that OpenSSL
+3.5 produces for each algorithm, by walking the DER rather than scanning it, so
+they are the identifiers this package actually interoperates on.
+
+| Parameter set | OID |
+|---|---|
+| ML-DSA-44 | 2.16.840.1.101.3.4.3.17 |
+| ML-DSA-65 | 2.16.840.1.101.3.4.3.18 |
+| ML-DSA-87 | 2.16.840.1.101.3.4.3.19 |
+| ML-KEM-512 | 2.16.840.1.101.3.4.4.1 |
+| ML-KEM-768 | 2.16.840.1.101.3.4.4.2 |
+| ML-KEM-1024 | 2.16.840.1.101.3.4.4.3 |
+| SLH-DSA-SHA2-128f | 2.16.840.1.101.3.4.3.21 |
+| SLH-DSA-SHA2-192s | 2.16.840.1.101.3.4.3.22 |
+| SLH-DSA-SHAKE-256f | 2.16.840.1.101.3.4.3.31 |
+
+Keys cross the boundary to OpenSSL as SPKI for public keys and PKCS8 for private
+keys, both carrying these identifiers, which is what makes the two backends
+interchangeable with each other and with any X.509 or CMS consumer that speaks
+the same encodings.
+
 ## What this evidence does not cover
 
 Stated plainly, because a conformance report that only lists what passed is

package/README.md

@@ -7,15 +7,18 @@ Post-quantum cryptography primitives for the KXCO stack.
 [![conformance](https://github.com/KnightsbridgeAIQ/kxco-post-quantum/actions/workflows/conformance.yml/badge.svg)](https://github.com/KnightsbridgeAIQ/kxco-post-quantum/actions/workflows/conformance.yml)
 [![license](https://img.shields.io/badge/license-Apache--2.0-blue)](./LICENSE)
 
-ML-DSA-65 (FIPS 204) and SLH-DSA-SHA2-192s (FIPS 205) signatures, ML-KEM-768 (FIPS 203) key encapsulation, and key fingerprinting utilities. Category 5 sets ML-DSA-87 and ML-KEM-1024 are also available. Wraps [`@noble/post-quantum`](https://github.com/paulmillr/noble-post-quantum). All other `kxco-pq-*` packages depend on this one.
+ML-DSA-65 (FIPS 204) and SLH-DSA-SHA2-192s (FIPS 205) signatures, ML-KEM-768 (FIPS 203) key encapsulation, and key fingerprinting utilities. Category 5 sets ML-DSA-87 and ML-KEM-1024 are also available. All other `kxco-pq-*` packages depend on this one.
+
+**On Node 24 and later the primitives run in OpenSSL 3.5**, not in JavaScript. Older Node and browsers use [`@noble/post-quantum`](https://github.com/paulmillr/noble-post-quantum). The two are interchangeable on the wire, which is checked rather than assumed: the interoperability matrix runs in full against both, and every report records which one produced it.
 
 **Evidence, not adjectives:**
 
 - [CONFORMANCE.md](./CONFORMANCE.md): NIST ACVP vectors for FIPS 203/204/205 (2,103 tests, 0 failed), and a cross-implementation interop matrix against liboqs, Bouncy Castle and two pure-Python implementations (225 checks, 0 failed, both directions, with negative controls), run against both backends. Reproducible: `npm run conformance:acvp`, `npm run conformance:interop`.
-- [BENCHMARKS.md](./BENCHMARKS.md): per-algorithm latency at p95/p99, plus memory. Two figures worth designing around: ML-DSA signing has a 4.5x tail between median and p99, and SLH-DSA-SHA2-192s signs in about 6.8 seconds.
+- [BENCHMARKS.md](./BENCHMARKS.md): per-algorithm latency at p95/p99 on both backends and on x86-64 and arm64, plus memory. Two figures worth designing around: ML-DSA signing keeps a rejection-sampling tail on either backend (5.1x median-to-p99 in JavaScript, 3.5x on OpenSSL), and SLH-DSA-SHA2-192s signs in seconds rather than milliseconds (4.3 s and 1.7 s).
 - [THREAT-MODEL.md](./THREAT-MODEL.md): what this defends against and what it does not. Read the side-channel section before deciding where a signing key lives.
 - [MIGRATION.md](./MIGRATION.md): moving an RSA or ECDSA system across, and moving between versions of this package.
-- [SECURITY.md](./SECURITY.md): reporting, and release integrity.
+- [SECURITY.md](./SECURITY.md): reporting, release integrity, and the dependency policy.
+- **Every release is reproducible and attested.** The published tarball rebuilds bit-for-bit from its own tag, verified in CI on every run, and each release carries a SLSA provenance attestation plus a CycloneDX SBOM at a permanent unauthenticated URL. A provenance attestation says a build happened in CI; the reproducible build says the artefact is the source. They are different claims and both are checkable without asking us for anything.
 
 ---
 

package/THREAT-MODEL.md

@@ -85,10 +85,13 @@ What that does and does not buy:
 - It **does** remove the structural impossibility. The reasoning above was that
   the property could not be established from inside the language at all. On the
   OpenSSL path it can, in principle, be established.
-- It **does not** amount to a constant-time claim from us. We have published no
-  timing measurements of either backend, and OpenSSL's post-quantum
-  implementations carry their own side-channel posture which is theirs to state,
-  not ours to assert on their behalf.
+- It **does not** amount to a constant-time claim from us. We have since
+  published timing measurements of both backends, reported at the end of this
+  document, and they detect nothing at their resolution. That is a bound, not a
+  clearance: a null result from a wall-clock test is weaker evidence than the
+  JavaScript backend's own statement that it does not defend against side
+  channels. OpenSSL's post-quantum side-channel posture is likewise theirs to
+  state, not ours to assert on their behalf.
 - It **does not** apply to Node 20 or 22, to browsers, or to any runtime without
   those primitives. Those keep the JavaScript backend and everything above
   applies to them unchanged.
@@ -207,6 +210,31 @@ falsifiable rather than permanent by assertion.
 - Published timing measurements under a statistical test such as dudect would
   turn "no claim" into a measured bound. Absence of a detected leak is not
   absence of a leak, and any such result would be reported that way.
+
+  **This one is now done, and the result is reported exactly that way.**
+  `bench/timing.mjs` runs a dudect-style Welch t-test on interleaved
+  fixed-versus-random secret key timings, and `npm run bench:timing`
+  reproduces it. At 3,000 iterations per class:
+
+  | Backend | ML-DSA-65 sign | ML-KEM-768 decapsulate |
+  |---|---:|---:|
+  | OpenSSL (Node 24+) | t = 0.027 | t = -0.93 |
+  | JavaScript (Node 22) | t = 0.454 | t = -0.658 |
+
+  dudect's convention treats \|t\| > 10 as a detected leak. Nothing here is
+  close to it.
+
+  **Do not read the second row as good news.** The JavaScript backend states
+  about itself that there is no protection against side-channel attacks, and
+  that statement is more authoritative than this measurement. A null result on
+  a path whose author says it leaks means the test is too coarse to see it, not
+  that it is absent: wall-clock timing at JavaScript resolution cannot resolve a
+  leak below its own noise floor, and it observes no cache, branch-prediction,
+  power or electromagnetic channel at all.
+
+  What the measurement is actually worth: it is a regression detector and a
+  published bound, not a clearance. If a future change introduced a leak large
+  enough to be visible at this resolution, this would catch it.
 - FIPS 140-3 validation of a module used underneath would change what can be
   asserted about the boundary, and is not the same as the algorithm-level
   conformance evidence in [CONFORMANCE.md](CONFORMANCE.md).

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "kxco-post-quantum",
-  "version": "1.5.1",
-  "description": "ML-DSA-65, ML-KEM-768 and SLH-DSA-SHA2-192s primitives with key fingerprinting. The base layer for all kxco-pq-* packages.",
+  "version": "1.5.3",
+  "description": "ML-DSA-65, ML-KEM-768 and SLH-DSA-SHA2-192s with key fingerprinting. Runs in OpenSSL 3.5 on Node 24+, JavaScript elsewhere. 2,103 NIST ACVP vectors and 225 cross-implementation interop checks, 0 failed. Reproducible builds, SLSA provenance, published SBOM. The base layer for all kxco-pq-* packages.",
   "keywords": [
     "post-quantum",
     "pqc",
@@ -112,10 +112,10 @@
   },
   "dependencies": {
     "@noble/hashes": "2.3.0",
-    "@noble/post-quantum": "0.7.1"
+    "@noble/post-quantum": "0.7.0"
   },
   "scripts": {
-    "test": "node --test test/basic.test.js && node --test test/context.test.js && node --test test/category5.test.js && node --test test/browser-smoke.test.js && node test/run-vectors.js",
+    "test": "node --test test/basic.test.js && node --test test/context.test.js && node --test test/category5.test.js && node --test test/edge-cases.test.js && node --test test/browser-smoke.test.js && node test/run-vectors.js",
     "test:vectors": "node test/run-vectors.js",
     "generate:vectors": "node test/generate-vectors.js > test/vectors.json",
     "bench": "node bench/bench.js",
@@ -123,6 +123,7 @@
     "conformance:acvp": "node conformance/run-acvp.mjs --json conformance/results/acvp.json",
     "conformance:interop": "node conformance/interop/run-interop.mjs --json conformance/results/interop.json",
     "sbom": "npm sbom --sbom-format cyclonedx --sbom-type library",
+    "bench:timing": "node --expose-gc bench/timing.mjs --iterations 20000 --json bench/results/timing.json",
     "bench:primitives": "node --expose-gc bench/primitives.mjs --iterations 100 --json bench/results/primitives.json"
   },
   "publishConfig": {