Ferrite.Your firewall rules are a file. Files can be edited.
If malware ever got write access to your rule store, the quietest thing it could do isn’t steal data — it’s delete the one rule blocking it, and let everything else keep working exactly as before. Ferrite signs the file specifically to catch that.
What’s actually signed
Every time your rule set changes, and again whenever it’s written to disk, Ferrite signs it with ML-DSA-65 — a NIST-standardized post-quantum digital signature algorithm, part of FIPS 204. On every load, that signature is checked against the on-disk bytes. If they don’t match — the file was edited by anything other than Ferrite itself — the engine refuses to load it rather than silently enforcing a rule set it can’t vouch for.
The settings store gets the same treatment, with a separate, cryptographically distinct signing context so a valid signature on one file can never be replayed onto the other. Settings aren’t an enforcement boundary the way rules are, so a settings mismatch is a loud warning rather than a hard refusal — the two files earn different responses because tampering with them means different things.
Why “post-quantum” specifically
This is the part worth being precise about, because it’s easy to overstate. A large enough quantum computer would eventually be able to forge signatures made with today’s classical algorithms (RSA, ECDSA) — not decrypt them, forge new ones from scratch. That’s a real, if distant, problem specifically for signatures that need to keep meaning something years into the future: if Ferrite signed your rule store with ECDSA today, the promise “only Ferrite could have produced this signature” would quietly stop being true the day forging ECDSA becomes practical — for every rule store signed with that scheme, not just old ones.
ML-DSA is built on lattice problems believed to resist both classical and quantum attacks, so that promise is designed to keep holding. Ferrite uses ML-DSA-65 specifically — NIST Security Level 3, roughly equivalent to 192-bit classical security, a 1,952-byte public key and a 3,309-byte signature. The implementation runs on aws-lc, Amazon’s open-source, FIPS-validated cryptography library — not a bespoke or unaudited crypto stack.
What this does not claim
This is signature integrity for a local file, not encryption of your network traffic. Ferrite doesn’t claim post-quantum protection for the connections it inspects or the data that crosses your network — that’s a different problem (transport encryption), and conflating the two would overstate what’s actually shipping. What’s real today is narrower and fully verifiable: your rule store can’t be silently edited out from under you, and that guarantee is built to keep holding even once quantum computers exist.
See it yourself
Settings → About shows the live signature status for both stores. Edit rules.toml directly with a text editor while Ferrite is closed, then relaunch — the engine will refuse to enforce the tampered file rather than loading it quietly. That refusal, not a badge or a claim, is the actual guarantee.