minisign / signify

signify and minisign are deliberately minimal tools for signing files and verifying those signatures. signify was written for OpenBSD to authenticate its releases and packages; minisign is a portable, actively maintained tool that is signature-compatible with signify, so a key or signature produced by one can be verified by the other. Both use the Ed25519 public-key signature system, which delivers strong security with tiny 64-byte signatures, small keys, and very fast verification — properties that make signing cheap enough to apply to everything you publish.

Why "small" is the point

PGP / GPG is powerful but sprawling: a complex key model, subkeys, expiry semantics, keyservers, a web of trust, and decades of accumulated options — each one a place to make a mistake. signify and minisign do exactly one job: prove that a file came from the holder of a specific private key and was not altered in transit. There is no keyring to manage and no trust graph to configure; the public key is a single short line of text you can paste into a README, print on a business card, or read aloud. When the file being verified is a wallet binary or a miner firmware image — software that will touch keys or hardware you care about — that simplicity removes whole categories of misconfiguration that have historically caused people to "verify" a download without actually verifying anything.

Trusted comments and anti-downgrade

minisign extends the format with a trusted comment: signed metadata, such as a version number, filename, or timestamp, that is verified along with the file itself (an untrusted comment field also exists, and the distinction is explicit). Binding a release to its version inside the signature helps defend against downgrade attacks, where an adversary serves you an older, genuinely signed but vulnerable build and hopes you will not notice the version. The verification command prints the trusted comment, so the check is right in front of you rather than buried in a detached changelog.

Verifying firmware the practical way

The workflow is short enough to actually follow every time. Obtain the project's public key once, from more than one channel if the stakes are high (repository, website, an announcement post), and store it locally. For each release, download the file and its .minisig signature, then run minisign -Vm file -P publickey; a pass means the bytes are exactly what the keyholder signed, and the trusted comment tells you which release you are holding. This matters most at flashing time: an SD image or firmware bundle that will run with full control over a machine deserves ten seconds of verification before it goes anywhere near an SD card or a web flasher. It is the same discipline this site applies to its own releases — signed artifacts you can check yourself, in the DCENT_OS spirit of verify-don't-trust.

Where they fit in the toolkit

These tools do not replace PGP everywhere — they do not encrypt, and they deliberately lack identity infrastructure — but for release signing they are frequently the better choice precisely because they cannot do anything else. They pair especially well with reproducible builds: independent rebuilders compile the source, confirm the output is bit-for-bit identical, and sign that artifact with minisign, giving downstream users a chain of custody from source code to the binary on their disk that no single compromised build server can forge.