KXCO Quantum Toolkit: The Cryptography You Did Not Choose Is Already in Your Software

Every company that has ever signed anything digitally is carrying a liability it has not measured. Not a hypothetical one about quantum computers arriving in 2032, though that is coming. A present one: almost nobody can tell you what cryptography is actually running inside their own software, and the auditors have started asking.

KXCO has spent the last year building the tools that answer that question, and we give them away.

What they are

Five packages, free, open source, on npm today.

**kxco-post-quantum** is the core. ML-DSA-65 for signatures, ML-KEM-768 for key exchange, SLH-DSA where a hash-based signature is wanted, all through a single interface built on established implementations pinned to an exact version. These are the algorithms NIST standardised as FIPS 204, 203 and 205 after an eight-year international competition. A team gets them without choosing a library, tracking its breaking changes, or owning its bugs.

**kxco-verify** answers whether a signature is mathematically valid. It is free and it stays free. We are not going to charge rent on arithmetic.

**kxco-pq-scan** reads your dependency tree and tells you where the vulnerable cryptography already is. It emits a CycloneDX 1.6 cryptographic bill of materials, so the answer is a standard document rather than a screenshot in an email.

**eslint-plugin-kxco-pq** fails the build when application code bypasses the wrapper and calls a raw primitive directly.

**kxco-pq-hsm** generates keys inside a PKCS#11 hardware security module as non-extractable objects, so the private key never enters ordinary computer memory at all.

The problem they solve

The hard part of this migration was never choosing an algorithm. NIST chose. The hard parts are the two nobody budgets for.

You do not know what you have. Scanning your own source code finds the cryptography your developers wrote, and in a modern application that is the smaller half. The rest arrived transitively, several levels down a dependency tree, inside a package nobody selected on purpose.

Here is a real example from a sample of common npm packages.

Four packages a team deliberately installed. One shared chain beneath them. At the bottom, ecdsa-sig-formatter, carrying the elliptic curve cryptography that Shor's algorithm breaks. Nobody chose it. It arrived four times over, underneath Firebase, Google authentication, Twilio and Passport. That single chain accounted for the majority of findings in the sample.

You cannot fix what you cannot locate, which is why naming the path matters more than naming the algorithm.

And you can hold the new thing wrong, silently. This is the one that costs people. Our wrapper takes the secret key first and the message second. The raw primitive underneath takes them in the opposite order. Transpose them and you still get a well-formed byte string of exactly the right length. It looks like a signature. It verifies as nothing. No exception, no warning, no failing test.

We know precisely how easy that is, because we did it ourselves last week while testing against a hardware token. Every offline test passed. The physical token was what caught it. That is the entire reason the lint rule exists.

Who needs this, and why

Any business shipping software with a signing or key-exchange dependency. Once you read a dependency tree honestly, that is close to everyone. If you issue an authentication token, verify a webhook, talk to a payment provider or connect two services, elliptic curve cryptography is already in your stack.

Regulated firms first. Banks, payment schemes, exchanges, custodians and market infrastructure are being asked already, and the question does not come from engineering. It comes from audit, and it arrives as: show me what cryptography you run, show me what you are doing about it, and show me when you knew.

Anyone facing a supplier questionnaire. The G7 has issued post-quantum guidance. The NSA's CNSA 2.0 sets a 2027 procurement gate for US national security systems. European standards bodies are moving. Customers will ask before regulators do.

And anyone putting an AI system near money. If a model can initiate a refund or a transfer, someone will eventually ask what it was permitted to do and who decided that.

How you use them

Start with the scan. One command, no account, no upload.

npx kxco-pq-scan

It reads the lock file on your own machine and prints what it finds. Add --cbom for the standards document you can attach to a change record, or --strict to make it fail a build.

Then adopt the wrapper where you sign, and switch the lint rule on in the same change so nobody can quietly bypass it later.

npm install kxco-post-quantum eslint-plugin-kxco-pq

The scanner is deliberately quiet where quiet is correct. AES-256 and SHA-2 are inventoried and left alone, because Grover's algorithm weakens those while Shor's algorithm breaks the others outright, and a tool that flags everything teaches its reader to ignore it. It also recognises hybrid constructions, so a modern pairing of a post-quantum algorithm with a classical one reads as the recommended migration path rather than a defect. Signal, not volume.

Why ours is different

Every claim is checkable without asking us. The libraries are tested against 2,103 official NIST validation vectors, pinned by digest so the test corpus cannot drift underneath us: 1,793 passed, none failed, and every skip is the library correctly refusing an option weaker than the parameter set. Every release carries a cryptographic provenance attestation linking the published package to the exact commit and build that produced it. Anyone can verify that in one command.

We publish our own corrections. Version 1.3.1 of our hardware module package claimed a key custody property the code did not implement. We shipped 1.3.2 as a documentation-only release naming the defect precisely, in the README, on npm, where every prospective user reads it. Then 1.4.0 implemented it properly, with the claim owned by a test against real hardware rather than a convenient stand-in. Most vendors would have fixed that quietly. The retraction is on the permanent record, and if you are evaluating cryptography from a company you have not met, that record should weigh more than any feature list.

How it fits together

The packages are not a product line. They are the floor everything else at KXCO stands on, which is why they are free and why they are maintained to a standard that would be excessive for marketing.

Armature L1 is a permissioned chain with instant finality where every block carries post-quantum verification from block zero. Not a retrofit and not a hybrid bolted on at a migration point. The same code in the free packages is what attests it.

KXCO Treasury, the economic operating system, moves value on that record. Sentinel is the quantum-resistant cloud and the trust layer for AI systems. The KXCO Ontology is where it becomes legible: every fact is a typed claim carrying its source, its as-of date, a confidence and a basis, or an explicit statement that the information is not available. Not a database of things. A record of who said what, when, and on what authority.

Above the packages sits KXCO Command, our licensed control plane, and it answers the question the free tools cannot. A signature being valid and a signature being permitted are different things. Command decides whether a given key is still allowed to sign right now, shows which counterparties break before you rotate it, constrains what an autonomous agent may do, and produces a sealed evidence pack that says so afterwards. Only the second question survives an audit.

Trust and compliance

KXCO is a member of the PKI Consortium, a contributor member of the Decentralized Identity Foundation, a participant in the Cloud Security Alliance Quantum-Safe Working Group and the CoSAI open project, and active in the IETF LAMPS working group. We hold an active NIST algorithm validation registration, a GLEIF legal entity identifier, ICO registration, and a published vulnerability disclosure policy.

The work aligns to NIST FIPS 203, 204 and 205, ETSI TS 119 312, UK eIDAS advanced electronic signature requirements, the G7 post-quantum mandate and NSA CNSA 2.0. A patent application covering identity-verified records anchored to a blockchain ledger is pending. The full list with registration numbers is at kxco.ai/corporate.

None of that substitutes for reading the code, which is why the code is open.

Who builds it

The packages are authored by Shayne Heffernan and John Heffernan with the KXCO engineering team, a small group of cryptography, distributed systems and platform engineers working across the chain, the control plane and the ontology. We do not publish a team page with headshots. The commit history is public and the work is the credential.

KXCO runs developer programmes for teams adopting the stack: integration support, review of your bill of materials output, and early access to the control plane for firms with a governance requirement rather than only a cryptography one.

Talk to us

If you are inventorying an estate, replacing a signing path, or facing a question from an auditor that your current tooling cannot answer, we would like to hear the specifics. The packages themselves will not need a conversation. The position around them usually does.

Contact KXCO for a briefing, an integration review, or access to the control plane. More on the group and the wider stack at kxco.ai/corporate.