kxco-post-quantum 1.5.1 → 1.5.2

package/CHANGELOG.md

@@ -1,5 +1,43 @@
 # 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.

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.1",
+  "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",
@@ -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": {