kxco-post-quantum 1.5.0 → 1.5.2

package/BENCHMARKS.md

@@ -15,7 +15,51 @@ node --expose-gc bench/primitives.mjs --iterations 100 --json bench/results/prim
 ```
 
 Every parameter set the package can reach is measured, not only the five it wraps
-in its own helpers.
+in its own helpers. The OpenSSL rows appear only on a runtime that provides those
+primitives, so run it on Node 24 or later to reproduce the comparison below and
+on Node 22 for the JavaScript figures alone.
+
+## Two backends
+
+Since 1.5.0 this package runs the FIPS primitives in OpenSSL 3.5 where the
+runtime provides them (Node 24 and later) and in JavaScript everywhere else.
+Those are different implementations, so one set of numbers cannot describe both.
+The harness measures whichever are available and labels every row, and the
+tables below the comparison are the JavaScript figures.
+
+| Algorithm | Operation | OpenSSL p50 | JavaScript p50 | OpenSSL p99 | JavaScript p99 | faster by |
+|---|---|---:|---:|---:|---:|---:|
+| ML-DSA-44 | sign | 1.125 | 5.116 | 4.619 | 21.325 | 4.5x |
+| ML-DSA-44 | verify | 0.241 | 1.373 | 0.725 | 2.451 | 5.7x |
+| ML-DSA-65 | sign | 1.293 | 8.074 | 4.562 | 40.840 | 6.2x |
+| ML-DSA-65 | verify | 0.288 | 2.249 | 0.652 | 3.803 | 7.8x |
+| ML-DSA-87 | sign | 1.879 | 11.031 | 7.128 | 39.404 | 5.9x |
+| ML-DSA-87 | verify | 0.613 | 3.363 | 1.831 | 5.843 | 5.5x |
+| ML-KEM-1024 | encapsulate | 0.126 | 0.708 | 0.278 | 1.986 | 5.6x |
+| ML-KEM-1024 | decapsulate | 0.230 | 0.919 | 0.339 | 1.630 | 4.0x |
+| ML-KEM-512 | encapsulate | 0.079 | 0.378 | 0.212 | 1.008 | 4.8x |
+| ML-KEM-512 | decapsulate | 0.236 | 0.461 | 0.380 | 1.498 | 2.0x |
+| ML-KEM-768 | encapsulate | 0.148 | 0.558 | 0.256 | 1.288 | 3.8x |
+| ML-KEM-768 | decapsulate | 0.183 | 0.874 | 0.523 | 5.378 | 4.8x |
+| SLH-DSA-SHA2-128f | sign | 68.639 | 97.791 | 165.092 | 173.466 | 1.4x |
+| SLH-DSA-SHA2-128f | verify | 3.459 | 6.082 | 4.303 | 27.278 | 1.8x |
+| SLH-DSA-SHA2-192s | sign | 1710.954 | 4342.105 | 1938.773 | 4628.987 | 2.5x |
+| SLH-DSA-SHA2-192s | verify | 1.263 | 7.457 | 2.405 | 40.920 | 5.9x |
+| SLH-DSA-SHAKE-256f | sign | 161.358 | 2158.272 | 179.655 | 3510.503 | 13.4x |
+| SLH-DSA-SHAKE-256f | verify | 5.599 | 66.177 | 6.774 | 98.654 | 11.8x |
+
+The speedup column is the headline, but for a document about tail latency the
+p99 columns matter more. ML-DSA-65 signing goes from a 40.8 ms p99 to 4.6 ms:
+the rejection-sampling tail that the opening of this document warns about is
+still there in the OpenSSL path, but it is roughly nine times tighter, so a
+timeout sized off it can be far smaller.
+
+SLH-DSA-SHAKE-256f is the largest single change, 2158 ms down to 161 ms for a
+signature. SLH-DSA-SHA2-192s remains slow in absolute terms at 1.7 seconds and
+no backend makes a hash-based signature cheap; it is 2.5x rather than fast.
+
+Neither column is a side-channel claim. See
+[THREAT-MODEL.md](THREAT-MODEL.md).
 
 ## Signatures
 

package/CHANGELOG.md

@@ -1,5 +1,67 @@
 # Changelog
 
+## 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.
+Exact pin as always, never a range.
+
+Worth taking rather than waiting for the scheduled Dependabot run, because one of
+its changes touches how this package calls it: 0.7.1 snapshots options on entry
+so a caller's object cannot be mutated afterwards. Every FIPS 204 context string
+this package passes goes in as an options object, so that hardening is directly
+on our path.
+
+It also adds a WebCrypto wrapper for ML-KEM upstream. Nothing here uses it yet,
+but it is worth knowing that the backend is converging on the same thing this
+package did in 1.5.0: use the platform's implementation where the platform has
+one.
+
+Verified before merging, on all three runtimes: 39 pinned vectors bit-for-bit and
+53 tests on Node 20 and 22 (the JavaScript path, where this bump actually
+applies) and on Node 24+ (the OpenSSL path).
+
+AUDIT.md carries the new pin and its integrity hash. The conservative bound is
+unchanged and restated: the maintainer's self-audit covers 0.6.1, we ship 0.7.1,
+so **the version we ship is covered by no audit at all**.
+
 ## 1.5.0
 
 **The FIPS primitives now run in OpenSSL where the runtime has them.** On Node 24

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/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,6 +1,6 @@
 {
   "name": "kxco-post-quantum",
-  "version": "1.5.0",
+  "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.",
   "keywords": [
     "post-quantum",
@@ -115,7 +115,7 @@
     "@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": {