Documentation

Quickstart

Install the scanner, scan a repository, and read the result. No dependencies, no network calls, nothing uploaded.

Install

One command. It downloads the binary for your machine from functorfund.com, checks its SHA-256 against the published checksums, and checks the checksums' ML-DSA-65 signature (NIST FIPS 204, post-quantum) against a public key pinned inside the script. It refuses to install on any mismatch.

curl -fsSL https://functorfund.com/quantum/install.sh | sh

Prefer not to pipe a script into a shell? Download install.sh, read it, then run it.

On Linux, most distributions ship an OpenSSL older than 3.5, which can't check ML-DSA signatures. The installer then still verifies the SHA-256 checksum, and warns that the signature was not checked. To require the signature, set QUANTUM_REQUIRE_SIGNATURE=1 on a machine with OpenSSL 3.5+ (macOS: brew install openssl@3), or verify by hand as below.

PlatformRelease
macOS (Apple silicon and Intel, one universal binary)v0.5.1
Linux x86_64 and arm64 (fully static, any distribution)v0.5.1
Windowsnot yet

Verify a download yourself

Every release folder holds the binaries, checksums.txt and checksums.txt.mldsa65.sig. With OpenSSL 3.5 or newer (macOS: brew install openssl@3):

V=$(curl -fsSL https://functorfund.com/quantum/releases/latest.txt)
B=https://functorfund.com/quantum/releases
curl -fsSLO $B/release-mldsa65.pub.pem
curl -fsSLO $B/v$V/checksums.txt -O $B/v$V/checksums.txt.mldsa65.sig -O $B/v$V/quantum-scan-darwin-arm64
openssl pkeyutl -verify -rawin -pubin -inkey release-mldsa65.pub.pem \
  -in checksums.txt -sigfile checksums.txt.mldsa65.sig      # Signature Verified Successfully
shasum -a 256 -c checksums.txt --ignore-missing                # quantum-scan-darwin-arm64: OK

Release key fingerprint (SHA-256 of the public key, DER): 8c09dfef97fd603d99f0fb46435140f5f73e2fc803ae9499a38d0e3f5cd1e080. A post-quantum scanner should be signed with a post-quantum signature; this one is.

Requirements

None at run time: a single binary, no dependencies, no network calls; it writes only the report file you ask for. The source is not public yet.

Your first scan

Point it at a directory. It walks the tree, matches rules, grades each match and writes a Markdown report.

quantum-scan . --out report.md --source-only

--source-only skips tests, vendored code, fixtures and documentation. Start with it: those directories generate most of the first-run noise, and none of it is production cryptography.

The summary is printed to the terminal:

Quantum Core PQ Scanner 0.5.1
-------------------------------------------
Target:             /path/to/project
Output:             report.md
Files scanned:      4

Weakness Score:     100/100 (Critical)
  broken today:     19 finding(s)

Migration Exposure: Pervasive
  asymmetric sites: 12 across 3 file(s) (75% of scanned)

Likely noise:       12

That example is the scanner's own tests/sample_project, which is deliberately full of bad cryptography. A real codebase looks different. Functor scans itself on every release: weakness score 0, and its quantum-vulnerable sites are all ECDSA signing. See Functor's own CBOM.

Reading the two scores

The report answers two separate questions and never mixes them.

MeasureQuestionGates CI
Weakness Score
0–100, severity weighted
What cryptography is broken today, on a classical computer? MD5, ECB mode, disabled TLS verification, hardcoded keys.Yes
Migration Exposure
sites, files, % of codebase
How much asymmetric cryptography must move before 2035? RSA, ECDSA, Ed25519, secp256k1, wallet and validator keys.No

A correct secp256k1 wallet scores 0 weaknesses and Pervasive migration exposure. It passes CI, and the report says it is healthy. A single combined score would have called that repository "Critical", which is how scanners lose the room.

What the report contains

The Markdown report is written to be read by a reviewer and attached to an audit.

  • Header — target, UTC timestamp, files scanned and skipped.
  • Both scores, with what each one means.
  • Executive summary — the weakness/inventory split in plain words.
  • Quantum reality note — states that hash functions and symmetric primitives are not broken by quantum computers, and that this is a signal scanner, not a proof of vulnerability.
  • Weaknesses — severity, CWE, rule, file, line and the matched text.
  • Inventory — the same, with a migration priority instead of a CWE.
  • Likely noise — low-confidence matches, listed rather than dropped silently, so the suppression is auditable.

Next

  • Continuous integration — the adoption path: baseline first, then raise the gate. GitHub Actions, GitLab and pre-commit recipes.
  • Command line — every flag, the exit codes, ignore files and inline suppression.
  • Rules and scoring — all 19 rules, how the score is computed, and the confidence model.
  • Output formats — Markdown, JSON, SARIF 2.1.0 and the CycloneDX 1.6 CBOM.