No upload to the cloud. No AI model in the loop. No multi-week configuration. A standalone scanner, deterministic by design, that reads your C/C++ source structurally and tells you which files are crypto haystacks worth your security team's attention.
Every Event Horizon scan moves through the same pipeline. Reproducible, deterministic, fast.
You point Event Horizon at a folder of C/C++ files. No network required. No upload. Standalone executable.
Each file is read structurally — the bone-shape of the code beneath variable names and comments. The structure is what matters; the surface text is cosmetic.
Seven independent structural detectors check every file. Each is tuned to one crypto-algorithm family. Multiple detectors can fire on a single file — that's the fingerprint.
Each fingerprint is compared against a labelled reference corpus drawn from PQClean, libsodium, BLAKE2, OpenBSD, FFmpeg, wolfSSL. Distance-to-cluster determines classification.
JSON, Markdown, and HTML dashboard, plus CycloneDX CBOM output for procurement pipelines. Every file sorted into one of four buckets. Drift comparison between scans is included — event-horizon drift earlier.json later.json reports what changed structurally over time.
When the scan finishes, you don't get a wall of CVE-style output. You get a structured triage. Each file lands in exactly one of these four buckets, ranked by priority for human review.
Detectors fired — so the file is crypto-shaped — but the fingerprint doesn't match anything in our reference catalogue. This is the priority-one category: a structured formation that nobody has mapped yet. Possibly a novel implementation, possibly a buggy variant, possibly something obfuscated. Deserves a cryptographer's eyes.
Typically 1-2% of files in a crypto-bearing codebase.
Detectors fired for the right family — but the fingerprint diverges from the documented reference. Often this is a deliberate optimisation (a constant-time variant, a hardware-accelerated path, a vectorised implementation). Sometimes it's drift from the original reference worth understanding. Always worth a look.
Typically 3-6% of files in a crypto-bearing codebase.
The file's fingerprint matches a known reference cluster cleanly. Structurally consistent with the crypto family it claims to be. Apply your standard family-specific review checklist; no surprises here. The bulk of well-maintained crypto code lands here, and that's the boring-good outcome.
Typically 5-12% of files in a crypto-bearing codebase.
No current detector fired. Typically these are parsers, networking, UI handlers, file I/O, data structures, general utilities — the 80-90% of any codebase that's not structurally crypto-shaped. To be clear: MUTE means "did not fire on current detectors," not "certified non-crypto." Save your team's time on the rest first; future releases expand family coverage.
Typically 85-95% of files in a typical codebase.
Different crypto families have different structural shapes. A round-loop body looks nothing like a hash-compression message schedule, which looks nothing like a butterfly-transform dependency graph. Event Horizon runs seven independent detectors — each tuned to one family — and reports which fired on each file. The combination is the fingerprint.
| Detector | Crypto family | What it identifies |
|---|---|---|
| R1 | Iterated permutation | AES round-loops, ChaCha quarter-rounds, Keccak rho/pi/chi — the classic block-cipher and permutation shape |
| R1-CT | Constant-time AES variants | Factored-call AES with table lookups, bitsliced constant-time implementations — the modern shape R1 misses |
| R1b | Hash compression | SHA-2 family message schedules, BLAKE2 compression bodies, MD5-style step functions — the hash-function inner loop |
| R1c | Butterfly transform | NTT layers in post-quantum lattice schemes (ML-KEM, ML-DSA, Falcon), FFT-style logarithmic dependency nesting |
| R1d | Polynomial arithmetic | Lattice-scheme polynomial-coefficient packing, Barrett/Montgomery reduction patterns, chunked-multiplicative indexing |
| R1f | Hash chain | SPHINCS+ WOTS+ chains, FORS tree leaves — the hash-based signature structural pattern |
| R1k | Composition wrapper | AEAD glue (GCM, ChaCha20-Poly1305), TLS record-layer assembly, file-level orchestration code with crypto-callee patterns |
Each detector has measured true-positive and false-positive rates on a labelled corpus, with bootstrap confidence intervals. The methodology paper documents every detector individually — share-on-request to qualified prospects.
Telling you what we don't do, up front, earns more trust than overpromising. Six things Event Horizon deliberately does not do:
We don't find bugs. We don't look for memory-safety issues, race conditions, or buffer overflows. SAST tools (Coverity, CodeQL, Semgrep) do that. AI scanners (Mythos, public-model equivalents) do that. We sit upstream — telling them which files are worth their time.
We don't test whether your AES produces the right output, or whether your SHA-256 matches the FIPS test vectors. That's CAVP (Cryptographic Algorithm Validation Programme) work. We test structural identity, not correctness.
We don't measure timing leaks, cache behaviour, or power-analysis resistance. That's specialised hardware-and-software testing. We can tell you a file structurally looks like a constant-time variant; we can't verify it actually is one at runtime.
An adversary who knows our fingerprint shape can hide inside it. Our threat model is honest mistakes, supply-chain drift, vendor-introduced variants, and accidental divergence — not nation-state implants. We're explicit about this.
A CONSISTENT result means "structurally matches a known reference" — not "bug-free", "side-channel-safe", or "approved by your regulator". Our output is a measurement, not a verdict. Your security team makes the call.
We sort files structurally into four buckets. We don't read them. Your cryptographer still has to read the UNKNOWN_PATTERN and BOUNDARY files. We're a focusing mechanism for existing expertise, not a replacement for it.
The window Palo Alto's CTO named is closing. The structural identification scan completes in minutes. The first conversation takes 30 minutes.
Book a 30-minute call →