For an independent assessor

The evidence, and the claims we do not make.

This page exists so nobody has to take a KXCO adjective on trust. The subject is kxco-post-quantum, an Apache-2.0 cryptography library on npm. Every number below comes from an artefact you can fetch without an account, and the last section lists what KXCO is not claiming, because an evidence page that only accumulates is not evidence.

$ curl -sL https://kxco.ai/.well-known/pqc-evidence.json

The same facts, machine-readable, against a published schema. Package versions in it are regenerated from the npm registry rather than typed.

What is being assessed

Two different things carry the KXCO name, and scoring them together produces a result that is true of neither.

SubjectModalityWhat it is
kxco-post-quantumlibraryApache-2.0, on npm, installs and runs with no KXCO account, no API key and no network call. Fifteen further Apache-2.0 packages build on it. This is the subject of this page.
KXCO registry and relayserviceA paid, KXCO-operated service that answers whether a key was revoked after a signature was made. Commercially licensed. Not assessed here.

The distinction matters because the commercial terms of the second are routinely recorded against the first. The library licence is Apache-2.0, which npm view kxco-post-quantum license confirms in one line.

Algorithms, by exact parameter set

Recorded in full in the evidence document. The names below are the FIPS names, not abbreviations.

Parameter setStandardNIST categoryPurpose
ML-KEM-768FIPS 2033key encapsulation
ML-KEM-1024FIPS 2035key encapsulation
ML-DSA-65FIPS 2043digital signature
ML-DSA-87FIPS 2045digital signature
SLH-DSA-SHA2-192sFIPS 2053digital signature
SLH-DSA-SHAKE-256fFIPS 2055digital signature

ML-KEM-512, ML-DSA-44 and SLH-DSA-SHA2-128f also ship, at Categories 1 and 2. Nine parameter sets in total. There is no SLH-DSA-128s in this library, and no such name exists in FIPS 205. Where a record shows one, it was not read from this package.

Conformance, graded two ways

2,130test cases graded by NIST ACVTS servers, zero failures. Demo certificate A11025.
1,793NIST ACVP vectors passed here, zero failed. The 310 skips are pre-hash pairings the library refuses as weaker than the parameter set, each listed with its reason.
225interoperability checks against liboqs, Bouncy Castle and two Python implementations. Both directions, negative controls included, zero failed.
33protocol checks on X.509 certificates and CMS SignedData issued by OpenSSL 3.5 and parsed by this library, zero failed.

On the ACVTS certificate. Certificate A11025, validation record /acvp/v1/validations/42204, module kxco-post-quantum 1.7.2 (Software), covering every algorithm the library ships at every parameter set NIST offers. It is a Demo certificate. It is not a CAVP validation, it does not appear on the public NIST algorithm validation list, and it is not a certification of KXCO as a firm. It is the reference NIST asks to be quoted when Production access is requested.

On the interoperability matrix. Peers are pinned by version: liboqs 0.16.0 built from source into a container, Bouncy Castle bcprov-jdk18on 1.85.2, and dilithium-py with kyber-py. Keys generated here verify there, and keys generated there verify here. Negative controls are included, so a matrix that passed by accepting everything would fail instead. Reproducible with npm run conformance:interop.

On sampling, stated rather than buried. Of the 2,103 ACVP vectors, 1,551 ship inside the downloadable bundle. SLH-DSA signature generation is sampled to 72 vectors there because it signs in seconds per operation, and the full set reproduces on demand. The bundle names that gap itself rather than leaving it to be noticed.

Side channels, split honestly

There are two backends and they do not carry the same guarantee. Pretending otherwise would be the easiest overclaim on this page.

PathWhen it runsWhat is claimed
OpenSSL 3.5Node 24+The primitives execute in OpenSSL. The constant-time properties are OpenSSL's, inherited rather than added by this library. This is the path intended for institutional signing.
@noble/post-quantumNode 20, 22, browsersNot claimed constant-time. JavaScript gives no control over timing, allocation or garbage collection. Do not put a high-value signing key on this path.
kxco-pq-hsmoptionalThe private key never enters process memory, held under PKCS#11 with CKA_EXTRACTABLE=false. That is a custody property, not a timing measurement.

Every generated report records which backend produced it, so no result is ambiguous about the code that ran. The reasoning is set out in THREAT-MODEL.md.

Supply chain

Four production dependencies, zero development dependencies, every direct dependency pinned to an exact version, no install scripts anywhere in the tree, and no known advisories. The published tarball rebuilds byte for byte from its own git tag, checked in CI on every run.

Provenance is not uniform, and the evidence document says so per package rather than in aggregate. Fourteen of the sixteen packages carry SLSA provenance attestations minted by npm through GitHub Actions OIDC. Two do not: eslint-plugin-kxco-pq, whose source repository is private, and kxco-post-quantum-webhook, whose current version was published outside the Trusted Publishing workflow. Both are named in the document with the actual reason. Verify independently:

$ npm audit signatures --json   # assert invalid:0 and missing:0

The CycloneDX SBOM and the in-toto provenance are release assets at permanent unauthenticated URLs, alongside the full evidence bundle.

Fetch the artefacts

$ curl -sLO https://github.com/KnightsbridgeAIQ/kxco-post-quantum/releases/latest/download/evidence-node24.x.zip
$ curl -sL  https://github.com/KnightsbridgeAIQ/kxco-post-quantum/releases/latest/download/manifest-node24.x.json

The manifest carries a SHA-256 for every file in the bundle, the git commit it describes, the toolchain that built it, and the exact command that produced each result. The bundle is SLSA-attested and signed with ML-DSA-65 against a public key committed in the repository, so the library signs its own releases with the cryptography it ships.

An independent verifier ships too. kxco-verify checks a deploy attestation in a terminal or a browser with no call to any KXCO server. It works with the network unplugged and keeps working if KXCO stops existing.

Evidence document · CONFORMANCE.md · BENCHMARKS.md · DEPENDENCIES.md · SECURITY.md

What KXCO does not claim

Stated plainly, so nobody has to infer it

  • Not FIPS 140-3 validated. kxco-post-quantum is not a validated cryptographic module and no validation is in progress. Implementing FIPS 203, 204 and 205 is not validation against them. As of 13 September 2026 no active FIPS 140-3 certificate anywhere carries ML-KEM or ML-DSA, so no vendor holds one.
  • Not CNSA 2.0 certified. ML-KEM-1024 and ML-DSA-87, both shipped, are on the CNSA 2.0 approved algorithm list. That is an algorithm mapping. KXCO is not a CNSA 2.0 validated product and does not assert compliance.
  • The ACVTS certificate is a Demo certificate, not a CAVP validation, and it does not appear on the public NIST validation list.
  • The JavaScript backend is not claimed constant-time, and no TVLA or masking analysis has been run on it. None is reported because none was performed.
  • Classical transport. Release signing is ML-DSA-65. The TLS that delivers the release is classical. That is stated rather than folded into the post-quantum claim.
  • No third-party security audit of this library has been published. The dependency review is ours, re-derived mechanically from the lockfile and the registry on every run, and it is labelled as ours.

If an assessment records something on this page differently, the artefact is fetchable, and we would rather be corrected against it than scored against a guess. Tell us what you found.

The evidence document The sixteen packages Contact KXCO