Fury · Post-quantum file encryption
A file encrypted today may be copied today and opened decades later. Fury is built for that: hybrid post-quantum key agreement by default, no classical fallback, and no way to write a private identity unprotected. Then it goes further — signatures, a metadata-private vault, and backups that notice when somebody rewrites history.
Traffic and archives captured today can be stored cheaply and opened when the mathematics catches up. Anything you encrypt with classical public-key cryptography is only confidential for as long as that assumption holds.
Fury starts with one job: turn a file into encrypted data that only the holder of the matching private identity can read, using key agreement chosen to survive that transition. Around that sit the pieces real archives need — who signed it, which recipient set it went to, where it is stored, and whether the backup you are about to restore is the one you left. Every part of it comes with a design document that says plainly what it does not protect against.
Every other choice in Fury follows from these — including the features it deliberately refuses to offer.
No classical public-key recipients and no silent downgrade path. There is no negotiation an attacker can push towards the weaker option, because the weaker option was never shipped.
The default suite combines FrodoKEM-640-SHAKE with ML-KEM-768 — two different lattice families. Your file stays confidential unless both assumptions fail for the same target.
New suites can become the default without old files becoming unreadable. Suite identifiers and stanza tags are wire constants and are never reused, so every shipped suite remains decryptable.
Private encryption and signing identities serialise only with a passphrase. There is no API, and no flag, for writing one in the clear — because the one that exists is the one that eventually leaks.
Static binaries, no cgo requirement, nothing to install alongside. Copy the binary to the machine that needs it and it works.
Four commands. One does the everyday encryption work; the others make identities, inspect files, and keep your key off the machines you do not trust.
The core
Generate an identity and Fury writes two files: the private identity you keep, and the public key you hand out. Anyone can encrypt to you; only you can open the result.
Key agreement
FrodoKEM-640-SHAKE and ML-KEM-768 both wrap the same file key. Breaking one is not enough — an attacker needs both to fall, for the same recipient, on the same day.
Identities
Private identities are encrypted with Argon2id and XChaCha20-Poly1305 before they touch the filesystem. Change the passphrase whenever you like; inspect and manage unlock methods without exporting anything.
fury1…, fingerprints as furyfp1…Authorship
A separate signing identity produces a detached signature that is only valid when Ed25519 and ML-DSA-65 both verify. Neither component can be stripped, and neither can be downgraded to on its own.
furysig1…, fingerprints as furysigfp1…Teams
A policy is a strictly parsed snapshot of up to 256 public keys with its own furypolicy1… digest. Encrypt to the policy, and when the team changes, rekey the ciphertext to a new one without re-encrypting the payload.
Trust
A signed profile ties a subject to exact encryption and signing keys, validity dates, a sequence number and revocation state, under an issuer you trust. Fury keeps durable local state and refuses anything that contradicts it.
Private Vault
Names, exact sizes, modes, timestamps and history live only inside encrypted records. On disk there are random identifiers and size-bucketed objects — locally or over SSH. Add, list, get, rename and delete, with every change recorded inside the encrypted catalogue.
fury audit reads back who changed what, and when they said soBackup
Every snapshot manifest is encrypted, composite-signed and chained to its predecessor. The trust anchor lives outside the repository, so a rollback, a fork or a replaced snapshot is detected rather than accepted.
Hardware
Enrol a FIDO2 security key as an unlock method, so opening a file needs a physical touch as well as a passphrase — and losing the laptop is no longer the same as losing the archive.
libfido2; stubs are refusedRemote work
The agent unlocks a header and returns only its file key, over a local or explicitly forwarded Unix socket. Identities, passphrases and plaintext never cross the protocol, and each request needs confirmation.
fury-agent audit verifyInspection
Describe an encrypted file — its suite, its recipient stanzas, its shape — without decrypting a byte. Then run the preflight: installation, identity permissions, recovery methods and authenticated backup continuity, all read-only.
--json --strict for monitoring that should page somebodyFor developers
The format is documented end to end — intro line, stanzas, header MAC, chunked payload, armour — and the same behaviour is available as a library, with the private-identity rule enforced in the API itself.
Fury is not unbreakable, military-grade or zero-knowledge, and it does not use those words. A .fury file protects contents, not filenames and not exact sizes; there is no forward secrecy, so a compromised identity exposes every ciphertext already sent to it; and rekeying rotates a recipient set rather than revoking anyone who kept the old copy. A vault hides names and timestamps but still leaks size buckets, object counts and access timing, and nothing detects hostile storage that deletes, withholds or replays records. Backups detect forks and rollback only through the trust anchor you keep outside the repository. Fingerprints authenticate keys, not people — verify important ones through a separate channel. And Go cannot guarantee key material is erased from memory, which Fury states rather than glosses over.
The whole model fits in a paragraph, which is the point. Cryptography people do not understand is cryptography people use wrongly.
One command produces your private identity and its matching public key. Choose a long passphrase, then back the identity up somewhere you would trust with the files it protects.
Give the public key — or just its short fingerprint — to whoever needs to send you something. It is not a secret and never was.
One command against the public key produces an encrypted file. Point it at a policy instead when a whole team needs access; each recipient gets their own wrapped copy of the file key.
Your identity and its passphrase — plus a touch of a security key, if you enrolled one — restore the original file. Everything else is detail you can read at leisure.
01The material must stay confidential for years, not months.
02You assume an adversary who stores everything and waits.
03Your archive backups leave your control the moment they leave the building.
04The filenames would give the game away on their own.
05Somebody needs to prove they produced a release, not merely encrypt it.
06You need a decryption key on a server you do not entirely trust.
07Your compliance position now names post-quantum readiness.
08You want to read the design document before you rely on the tool.
Because post-quantum cryptanalysis is young. Combining two different lattice families means the file key survives unless both assumptions fail for the same target. It costs a little size and time, and buys a great deal of margin. The signatures work the same way: Ed25519 and ML-DSA-65 must both verify, so neither can be stripped away.
Not by itself, and deliberately so. Encryption gives confidentiality; anyone holding your public key can encrypt to you, which is what a public key is for. When authorship matters, sign the file with a separate signing identity — the signature is what authenticates the author. Even then, a fingerprint authenticates key bytes; a signed recipient profile is what binds those bytes to a named subject under an issuer you trust.
They keep opening. Decryption dispatches on the tag written into each file, suite identifiers are never reused, and every suite Fury has shipped stays decryptable. Agility was designed in from the start rather than bolted on at the first migration.
A vault is a working store where the metadata is secret: names, sizes and timestamps are encrypted, and you add, replace and delete files over time. A backup is an immutable signed chain of snapshots you restore from, with fork and rollback detection anchored outside the repository. Different jobs; most teams that need one eventually want both.
Yes — and that is the honest answer for any tool worth using. Lose the private identity and its passphrase, and nothing recovers the data. Lose a backup's trust anchor and Fury forgets what that repository is meant to look like. Back both up, choose a passphrase you will still know next year, enrol a second unlock method before you need it, and run a restore drill while it is still a drill.
Fury is free software under version 3 or later of the GNU General Public Licence. Read it, audit it, build it yourself — it needs Go 1.26.6 or newer, which is a security requirement rather than a preference — and get in touch if you would like help deploying it across a team.
Independent products, built because they should exist.
4ensics Leviathan
A complete binary analysis, reverse-engineering and digital-forensics workbench, running inside a browser tab with your artefacts kept local.
See LeviathanBlackwall
OAuth 2.1 and OpenID Connect with passkeys only, an integrity-chained audit log and signed project licences — in a single binary.
See BlackwallNeoCMS
Controlled visual editing, drafts and publishing for an existing static website — with ordinary HTML still served to the public.
See NeoCMSAsk about rolling Fury out across a team, standing up a vault or a signed backup repository, integrating the library, or whether post-quantum encryption is genuinely the right answer to the problem in front of you.
[email protected]