A3E9 logoA3E9
All evidence

// CBOM · NO_LOGIN_REQUIRED

An Inventory of Every Algorithm, Signed and Downloadable.

A cryptographic bill of materials answers a question a reviewer would otherwise have to ask by hand: which primitives does this thing actually contain? A3E9 generates one in CycloneDX 1.6 from a source scan, signs it, and fails the build when the code grows a mechanism the inventory does not account for. All three files are below, with a verify that runs on OpenSSL alone.

// DOWNLOAD

Three Files, Served Byte-Identical.

They are useless apart. The inventory without the signature is a file you cannot distinguish from one we edited on the way out; the signature without the key is a check you cannot run.

Envelope, as served

cbom_sha256
f6523a11ba443a4248fa87c874616d792058be17826f21654ffc28a1273b7237
signed_at
2026-08-08T21:47:47Z
public key
1ef4dd7e8b79d94fdc53161f1344a0ea4e2e2bf5c0db84911184469545f8e696

// WHAT_THIS_SIGNATURE_IS_NOT

A Development Key Signed This.

The signature verifies. It is still not an attestation, and the difference decides how much weight the artifact carries.

Read before citing this signature

The signing key is a development Ed25519 key held in a software SoftHSM2 token, not a production HSM key. A signature made with it is cryptographically valid and attests to nothing an auditor should rely on.

The envelope’s key_label field reads A3E9-ATTESTATION-KEY-PROD. That is the label the signing tool was asked to record — it is not evidence of which key signed, and the production key of that name did not exist in the token where this was produced. The field is named here because the .sig file travels independently of this page, and read on its own that line invites precisely the wrong conclusion.

What the signature is good for: change detection. It proves the bytes served here are the bytes that were signed, so a modified inventory fails the check. It does not tie the inventory to a production HSM, and nothing published today does.

// VERIFY_IT

Five Commands, OpenSSL Only.

Every command below was run against the exact files this page links to before it was published. Nothing here needs A3E9 software, a token, or a clone of a private repository — a verification that requires a tool only we ship is not independent verification.
# 1. Fetch all three files
curl -sO https://a3e9.com/evidence/CBOM.json
curl -sO https://a3e9.com/evidence/CBOM.json.sig
curl -sO https://a3e9.com/evidence/cbom_signing_key.pub

# 2. The digest in the envelope must match the file you were served
sha256sum CBOM.json
grep '^cbom_sha256=' CBOM.json.sig

# 3. Rebuild the public key as a DER SubjectPublicKeyInfo, then PEM
HEX=$(grep -v '^#' cbom_signing_key.pub | tr -d '[:space:]')
printf '302a300506032b6570032100%s' "$HEX" | xxd -r -p > pub.der
openssl pkey -pubin -inform DER -in pub.der -out pub.pem

# 4. Extract the base64 signature and the raw digest it covers
sed -n '/^---BEGIN/,/^---END/p' CBOM.json.sig \
  | grep -v '^---\|^cbom_sha256=\|^key_label=\|^signed_at=' \
  | tr -d '\n' | base64 -d > sig.bin
sha256sum CBOM.json | cut -d' ' -f1 | xxd -r -p > digest.bin

# 5. Verify. Ed25519 over the 32 raw digest bytes.
openssl pkeyutl -verify -pubin -inkey pub.pem -rawin -in digest.bin -sigfile sig.bin
# -> Signature Verified Successfully

The signature is Ed25519 over the 32 raw digest bytes rather than over the file, which is why step 4 builds digest.bin instead of passing the JSON directly. If step 2’s two values disagree, stop — the file you were served is not the file that was signed, and step 5 will fail for that reason rather than for a key reason.

// WHAT_IT_INVENTORIES

Cryptographic Assets, Not Just Packages.

A dependency SBOM lists libraries. A CBOM lists the cryptography those libraries are used for — which is the part that matters when the question is post-quantum readiness or algorithm deprecation.

What is in this file

23 components: 18 algorithm assets, 1 protocol asset, and 4 libraries — OpenSSL 3.0.13, SoftHSM2 2.6.1, liboqs (Open Quantum Safe) unpinned, Craton HSM (in-tree software PKCS#11 module) in-tree @ a0252b7.

The blocking CI gate

Adding a PKCS#11 mechanism to the code fails the build until the inventory accounts for it, either by mapping it to an asset or by recording a reasoned exemption. The inventory cannot silently fall behind the code, because the code will not compile past it.

How it reconciles with the vector coverage

The conformance report is derived against this inventory: of 18 algorithm assets, 4 have known-answer vectors wired and 14 do not. Those 14 are listed by name in the report rather than summarised as a gap, and the derivation is automatic — wiring a test removes a primitive from the uncovered list with no manual edit.

Two scan gaps, recorded upstream

The under-claim gate keys on PKCS#11 mechanism tokens, so a primitive added purely in software through OpenSSL EVP would not trip it. And the private attestation submodule sits outside the scan roots, so a novel primitive added inside it would not appear here. Both are recorded in the conformance record's own automation-limits list rather than left to be discovered.

Limit

A CBOM is not a substitute for a full software bill of materials of the product, and this one does not claim to be. It inventories cryptography; it says nothing about the rest of the dependency graph. No row in it is a certification of any algorithm it names, and the post-quantum entries carry the same fence as everywhere else on this site — liboqs is not a FIPS-certified module.

// WHAT_A_TOKEN_ADDS

The CBOM describes a build. A token confirms the image actually running is that build, which no downloadable file can establish about itself.

Everything above is checkable without contacting anyone, and is meant to be read first. The token exists because the remainder needs a provisioned environment — not because the evidence is being held back.