kxco-post-quantum 1.5.2 → 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,27 @@
 # 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

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/package.json

@@ -1,7 +1,7 @@
 {
   "name": "kxco-post-quantum",
-  "version": "1.5.2",
-  "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",