The builds are released to a named organisation, because we have to be able to answer “who holds this binary” when a security review or an advisory asks. The documents you would use to check the binary — every SBOM, the SHA256SUMS file, its Ed25519 signature — are public, ungated, and linked below. Read those first. Nobody should have to introduce themselves to find out what is inside software they have not decided to run.
A gate that hides the SBOM does not protect anything — an SBOM is worth nothing to someone trying to avoid paying, and everything to the reviewer deciding whether this software may be installed at all. So the line is drawn where it actually matters, and it is drawn in one place in the code rather than in copy on this page.
Gated · one short form
Public · no form, ever
Federal and enterprise reviews start with the SBOM and the signature, often months before anyone talks to a vendor. A form in front of those documents would not slow down a freeloader for a minute; it would end that review. This is the reason the split exists, and it is not negotiable per-deal.
Most trials cripple the product and hope you imagine the rest. This one does the opposite, because an assessor mid-engagement on an air-gapped network cannot renew a licence, and a scanner that degrades detection over entitlement is a scanner nobody can depend on. Detection is never reduced. What an unlicensed build cannot give you is the one thing a licence is for: output you can put in front of an assessor.
Installing a licence removes the watermark, the banner and the card, and names your organisation and tier in their place. Nothing else about the scan changes — the same input produces the same findings either way.
Licence state and rule-bundle state are independent, and they stack. Rules are only evidence-grade when they came from a current bundle whose Ed25519 signature verified against the key pinned in the binary; until one is imported the pack carries a second watermark, UNSIGNED RULES — NOT VALID AS EVIDENCE. Run cipherm version on your install and read the evidence-grade line — it names every reason the current install is or is not evidence-grade, and it is authoritative in a way this page cannot be.
One form covers every build for a fortnight — this page does not guess what you are running, because an enterprise buyer downloads for a machine that is not the one in front of them: a build server, an air-gapped workstation, a laptop being prepared for an engagement. If you already hold a licence, redeem the order key that came with it instead and skip the form.
Checking for an existing grant…
These are the files a security review actually reads first, and every one of them is served to anyone who asks. The SBOMs describe the executables, one per binary, not the project in general. SHA256SUMS carries the digest of every artifact in the release, including the ones behind the form — so you can check a copy that reached you through procurement, a mirror, or a USB stick, without ever using this page to fetch it.
| File | What it is | Size |
|---|---|---|
| cipherm-1.0.0-macos-arm64.cdx.json sha-256 3677da16d54fc20ff6267c8a0209d2f134934ec1cfae520522293c1feabfae95 | CycloneDX 1.6 SBOM | 80.8 KiB |
| cipherm-1.0.0-macos-x86_64.cdx.json sha-256 54d13f6f7a4a5f34ad26145af92694048d65724bead42727ed0b09f78825cd6e | CycloneDX 1.6 SBOM | 78.0 KiB |
| cipherm-1.0.0-linux-x86_64.cdx.json sha-256 10d12495df5fe1764b499539699623f461240857edcaba1a335434d7fd77ecfa | CycloneDX 1.6 SBOM | 83.8 KiB |
| SHA256SUMS sha-256 34e5ff7dd9aa9e5acd0cf9d34b5ca6ed17c3b96faeef267ea74ff798445f530d | Checksum file | 751 B |
| SHA256SUMS.sig sha-256 ba859ce1321e611c5eb39db527788fd1c1c902be04ca908024662de75dafa292 | Detached Ed25519 signature | 64 B |
SHA256SUMS.sig is a detached Ed25519 signature over the exact bytes of SHA256SUMS, made with ed25519:bcf6f281bddef43a. Download both — a digest published on the same page as the file it describes proves the copy is complete, not that it is ours.
HTTPS proves you reached our host. It does not prove the file is the one we built. Two independent checks do that: the SHA-256 of the bytes you received, and an Ed25519 signature over the checksum file made with a key whose public half is compiled into the binary you are about to run.
Compare the output against the digest printed beside the download, or against the line for that file in the public SHA256SUMS. On Linux use sha256sum in place of shasum -a 256.
shasum -a 256 cipherm-1.0.0-macos-arm64
shasum -a 256 -c --ignore-missing SHA256SUMS
Checks every artifact you downloaded in one pass. Files listed in SHA256SUMS that you did not download report as missing; that is expected.
This is the check that establishes provenance rather than integrity. Write the published key to a file, then verify the detached signature against it.
cat > cipherm-release.pub.pem <<'PEM' -----BEGIN PUBLIC KEY----- MCowBQYDK2VwAyEAPIkXsrQ/u3ogb1JPEXp+gNXNsaCQMsifRIdEtXAxf4M= -----END PUBLIC KEY----- PEM
The public half of the release key. It is the same key pinned in the binary's trust store, so you are not asked to trust this page for it.
openssl pkeyutl -verify -pubin -inkey cipherm-release.pub.pem \ -rawin -in SHA256SUMS -sigfile SHA256SUMS.sig
Prints “Signature Verified Successfully”. Any other output means stop — do not run the binary, and tell us.
The key id is not a label we assert; it is derived from the key. It is ed25519: followed by the first 16 hex characters of the SHA-256 of the raw 32-byte public key. Recompute it from the PEM you just wrote and compare it to the id published on this page.
openssl pkey -pubin -in cipherm-release.pub.pem -outform DER \ | tail -c 32 | shasum -a 256 | cut -c1-16
Must print bcf6f281bddef43a — matching the release key id on this page. The same id appears in every signed rule bundle and every licence file.
ed25519:bcf6f281bddef43aRun these only against the macOS artifacts, and read the build table first: it states per build whether that build is signed and notarised. If it says a build is unsigned, these commands are expected to fail, and their failure is not evidence of tampering — the SHA-256 and the signature are.
codesign --verify --strict --verbose=2 cipherm-1.0.0-macos-arm64
spctl --assess --type install CipherM-1.0.0.pkg
xattr -d com.apple.quarantine cipherm-1.0.0-macos-arm64
Only after the checksum matches. A file that arrives via a browser, AirDrop or Mail carries a quarantine attribute; on a build that is not notarised, Gatekeeper will refuse to open it until the attribute is cleared. Files copied from a USB stick or an internal share usually carry no quarantine attribute at all.
selfcheck imports every module compiled into the binary, reloads the rule bundle and compares its count against the build stamp, re-hashes the rules against the manifest, and renders the dashboard page. No network, no arguments, no configuration. If a transfer truncated the file or an endpoint agent modified it, this is where it shows up.
chmod +x cipherm-1.0.0-linux-x86_64 ./cipherm-1.0.0-linux-x86_64 selfcheck ./cipherm-1.0.0-linux-x86_64 version
version prints the engine version, the rule-bundle version and age, the licence state, and an evidence-grade line that lists every reason the install is or is not evidence-grade. On a fresh unlicensed install it says NO and explains why. That is correct behaviour, not a broken install.
The longer procedure — including fleet deployment, MDM notes, the state directory and Appendix A on code-signing status — ships with the release as docs/verifying-a-release.md and docs/desktop-install.md, and is reproduced on the CipherM Desktop page.
Written for a one-way transfer window you do not get to repeat. Every check on the far side is local: SHA-256 needs no network, the signature check needs no network, and CipherM itself never makes one. The only thing you cannot do on the far side is fetch something you forgot — so the first step is a list.
The executable for the target platform — not the platform you are browsing on — plus that executable's .cdx.json SBOM, plus SHA256SUMS, plus SHA256SUMS.sig. If the far side is macOS and you intend to use the installer, take the .pkg instead of the bare executable. Take the current signed rule bundle (.crb) and your licence file (licence.json) in the same window if you have them; both are data and neither requires a new binary.
Run the checksum check and the signature check here, where you can still re-download. A bad copy discovered on the far side costs you a transfer window; a bad copy discovered here costs you thirty seconds.
Carry SHA256SUMS and SHA256SUMS.sig by a different route than the binary — a printout of the digest, a separate stick, a signed email. A checksum that travelled beside the file it describes proves the copy is complete, not that it is authentic.
dot_clean /Volumes/USB strips the AppleDouble ._* sidecars macOS writes to FAT and exFAT. CipherM ignores them, but they inflate the transfer and they confuse checksum tooling that globs a directory.
shasum -a 256 -c --ignore-missing SHA256SUMS, then the openssl signature check if OpenSSL 3.0+ is present on that host. If it is not, the SHA-256 comparison against a digest you carried separately is what you have, and it is enough to detect a corrupted or substituted transfer.
sudo install -m 0755 cipherm /usr/local/bin/cipherm on Linux; copy plus xattr -d com.apple.quarantine on macOS. Then cipherm selfcheck, then cipherm version. State — licence, bundles, trusted keys — lives in ~/.cipherm, or wherever CIPHERM_HOME points, so the binary itself can sit on a read-only share.
cipherm licence install licence.json, then cipherm rules verify <bundle>.crb to inspect it without installing, then cipherm rules import <bundle>.crb. Import verifies the bundle's Ed25519 signature against the key pinned in the binary, refuses a bundle older than the one installed, and writes nothing unless verification passes. Re-run cipherm version and confirm evidence-grade now reads YES.
One connected host downloads and verifies, then publishes to Artifactory, Nexus or a file share, and the fleet imports from there. It is the same shape you already use for offline vulnerability-feed distribution, files from an internal share carry no quarantine attribute, and one download grant covers the whole estate.
Nothing in this sequence contacts a licence server, a rule server, or a telemetry endpoint, because none exist. The gate on this page is a web-server door, not a runtime check: once the bytes are on your side of the boundary, CipherM never asks anyone for permission again. If your egress monitoring ever records CipherM making an outbound connection, that is a finding worth reporting to us.
CipherM version
1.0.0
Released
2026-08-01
Engine
0.3.0
Rule bundle
2026.09
Signing key id
ed25519:bcf6f281bddef43a
Hosting
Vercel Blob · private · served only through /api/download
The build is byte-for-byte reproducible on a single machine with a pinned toolchain: PYTHONHASHSEED=0 is always set and SOURCE_DATE_EPOCH is honoured, and that property is measured on every build rather than assumed. It is not yet independently reproducible by a customer on their own hardware, and we do not claim it is. What that would take — a pinned container, a published toolchain manifest, and a second builder — is documented in the repository rather than promised here.
A digest published beside its file proves the copy is complete. The Ed25519 signature over SHA256SUMS is what proves the set is ours, and it is only as good as your confidence in the key — which is why the key id is derivable from the key itself and the same key is pinned inside the binary. Custody of the private half is a macOS Keychain item on one machine, not an HSM: a deliberate, documented tradeoff for a first release, and a hardware token is the right answer before the first federal engagement.
Scan your real estate with the unlicensed build, read the findings, and decide whether the evidence pack is the artefact your assessor actually wants. If it is, a licence turns the same output into something you can submit. If it is not, you have spent an afternoon and one form, and you can read every SBOM and digest on this page again without either.