Developers
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.
The evidence document
Every number below comes from an artefact you can fetch without an account. 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.
| Subject | Modality | What it is |
|---|---|---|
| kxco-post-quantum | library | Apache-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 relay | service | A 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 set | Standard | NIST category | Purpose |
|---|---|---|---|
| ML-KEM-768 | FIPS 203 | 3 | key encapsulation |
| ML-KEM-1024 | FIPS 203 | 5 | key encapsulation |
| ML-DSA-65 | FIPS 204 | 3 | digital signature |
| ML-DSA-87 | FIPS 204 | 5 | digital signature |
| SLH-DSA-SHA2-192s | FIPS 205 | 3 | digital signature |
| SLH-DSA-SHAKE-256f | FIPS 205 | 5 | digital 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 and interoperability
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. Signatures made with keys generated in kxco-post-quantum verify in the pinned peer libraries, and signatures made in those libraries verify here. Negative controls are included, so a matrix that passed by accepting everything would fail instead. Reproducible with npm run conformance:interop.
Side channels, split honestly
There are two backends and they do not carry the same assurance. Pretending otherwise would be an easy overclaim.
| Path | When it runs | What is claimed |
|---|---|---|
| OpenSSL 3.5 | Node 24 and later | 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-quantum | Node 20 and 22, browsers | Not 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-hsm | optional | The 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
The published tarball rebuilds byte for byte from its own git tag, checked in continuous integration (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 provenance attestations in the SLSA (Supply-chain Levels for Software Artifacts) format, issued by npm through GitHub Actions OpenID Connect (OIDC) login. 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 software bill of materials (SBOM) and the in-toto provenance are release assets at public URLs that need no login, 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 (FIPS 204) 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 checks the signature with the network unplugged and keeps working if KXCO stops existing. It cannot tell you whether the signing key was revoked after the signature was made; that check needs the KXCO registry.
Evidence documentCONFORMANCE.mdBENCHMARKS.mdDEPENDENCIES.mdSECURITY.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.
- 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.
- No CAVP algorithm validation. kxco-post-quantum does not appear on the public validation list of NIST's Cryptographic Algorithm Validation Program (CAVP). KXCO's own runs of NIST's published test vectors are not a NIST validation.
- The JavaScript backend is not claimed constant-time. No test vector leakage assessment (TVLA) or masking analysis has been run on it. None is reported because none was performed.
- Classical transport. Release signing is ML-DSA (FIPS 204). The TLS that delivers the release is classical. That is stated rather than folded into the post-quantum claim.
- No third-party security audit. No third party has audited this library. 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.