# Minisign: Ed25519 File Signing Without the GPG Overhead

> Minisign is a small C tool that signs files with Ed25519 and verifies them against a short public key string. It is aimed at release engineers and package maintainers who want signatures without a keyring, and its README now points new work at a Zig rewrite.

**jedisct1/minisign** — A dead simple tool to sign files and verify digital signatures.

- Repository: https://github.com/jedisct1/minisign
- Website: https://jedisct1.github.io/minisign/
- Stars: 2,837 · Forks: 154
- Language: C
- License: ISC
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/jedisct1-minisign

## What Minisign replaces, and for whom

The problem is narrow. You built a tarball or a binary, you put it on a server, and a user wants to know it was not swapped in transit. GPG can answer that, but the answer arrives wrapped in key servers, trust models, subkey expiry and a keyring that has to be initialised before the first signature means anything. Minisign answers the same question with one Ed25519 key pair and a detached signature file. The README describes the design goals as simple to use, secure, minimal and cross-platform, and the usage section is three commands long. The audience is release engineers, package maintainers and anyone publishing artifacts who is willing to trade GPG's ecosystem for a smaller set of guarantees. The README's own verification instructions show the shape of that trade: the project's releases are checked against a single public key string, RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3, pasted directly into the command line. There is no key server lookup and no trust path to reason about. That is the whole pitch, and it is also the whole limitation.

## Ed25519 keys, detached signatures and the .minisig file

The mechanism is Ed25519, a public-key signature system the README notes for small and fast signatures. minisign -G generates two files: minisign.pub, the public key, and minisign.key, a password-protected secret key. Signing with minisign -S -m file.txt produces file.txt.minisig next to the input, so the signature travels as a separate artifact rather than being embedded in the file. Verification takes the message, the signature and a public key, either from a file with -p or as a literal string with -P. The signature format is compatible with signify, the OpenBSD signing tool: the README states that signatures created with signify can be verified with minisign and vice versa. That compatibility is why the format shows up outside this project, and it is the reason a Rust or Go reimplementation can be dropped into an existing pipeline. Signatures are deterministic in this implementation, unless libsodium was compiled with ED25519_NONDETERMINISTIC defined, which the Dockerfile does. The README is explicit that non-deterministic implementations remain fully interoperable with deterministic ones, so the choice affects reproducibility of the signature bytes, not the ability to verify.

## Installing Minisign on macOS, Windows and Linux

The README lists prebuilt packages for three platforms. On macOS, Homebrew; on Windows, Scoop or Chocolatey. Run the one that matches your machine:

```bash
brew install minisign
```

```bash
scoop install minisign
```

```bash
choco install minisign
```

Linux is not in that table. The README's installation section covers building from source instead, with two toolchains. The Zig path needs zig 0.15.1 or later and optionally libsodium, and the README gives three variants: dynamic linking against libsodium, static linking with -Dstatic, and a build with no libsodium at all. The resulting binary lands in zig-out/bin/minisign. The CMake path requires libsodium, CMake, pkg-config and GCC or Clang, and installs system-wide. If you cannot find a distro package, that absence is the reason: the README does not document a Linux package-manager entry, so source builds and the Docker image are the supported routes. The Docker image is the shortest path to a working binary with no local toolchain:

```bash
docker run -i --rm jedisct1/minisign
```

The README notes the image can be verified with a cosign public key, which is the one place this project leans on another signing system.

## A first signing and verification workflow

Generate the key pair once. The README shows the single flag:

```bash
minisign -G
```

You are prompted for a password, and you get minisign.pub and minisign.key in the working directory. Sign a file, optionally attaching a trusted comment that is covered by the signature:

```bash
minisign -S -m file.txt -t "Trusted comment here"
```

This writes file.txt.minisig. Verify it against the public key file:

```bash
minisign -Vm file.txt -p minisign.pub
```

Or skip the file and pass the key inline, which is what the README does for its own releases:

```bash
minisign -Vm file.txt -P RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3
```

The README's Docker example adds -s minisign.key to select the secret key and mounts the working directory at /minisign, which matters because the container's entrypoint runs as an unprivileged user and cannot see your home directory. The README also states plainly that you should back up the private key and not commit or share minisign.key. Treat that as the operational rule for the whole workflow: the public key is meant to be pasted into download pages and CI configs, the secret key is meant to sit on one machine.

## Where Minisign is the wrong tool

There is no revocation. If minisign.key leaks, the README documents no mechanism to withdraw the corresponding public key, and no expiry date is set at generation time. A user who has your public key string has no way to learn it is now untrusted. GPG has revocation certificates and expiry for exactly this reason. There is also no identity binding. Minisign proves that whoever holds a given secret key signed a file; it does not tell you who that is, and there is no signature timestamp or transparency log to check when a signature was made. The trusted comment is signed but is free text, not a policy. Distribution is manual: you have to publish the public key somewhere trustworthy, and the README does not describe a discovery mechanism. Finally, the README states that minizign, a Zig implementation, is now the recommended implementation and where new features will be implemented. That is a direct signal about where to expect future work, and anyone standardising on the C tool should read it as a maintenance boundary rather than a footnote.

## Minisign against GPG and Sigstore

GPG and Minisign differ in scope, not just in ergonomics. GPG supports RSA, ECDSA and EdDSA, multiple identities per key, subkeys, expiry, revocation, and a web of trust with key servers. Minisign supports one key type and one key pair per file, with no revocation and no identity layer. If your threat model is "did this file arrive intact from the person who holds this key", Minisign is sufficient and much smaller. If it is "is this key still valid, and who vouches for it", Minisign has no answer. Sigstore, which appears in the related searches and is referenced here only through the Docker image's cosign verification key, takes a third approach: short-lived certificates bound to an OIDC identity and a transparency log. That removes long-lived secret keys entirely, at the cost of a network dependency at signing time and a much larger surface. Minisign's trade is the opposite: a long-lived key you must protect, but a verifier that works offline with one string. The README's own list of implementations, including rsign2 in Rust, go-minisign, rust-minisign, py-minisign and a .NET library, is the practical argument for the format: verification can be embedded in a language you already ship, without shelling out to a binary.

## Maintenance, releases and the ISC licence

The last push to the repository was on 2026-08-26, so the project is not dormant, but the release cadence is slow and worth planning around: 0.10 in 2021, 0.11 in 2023, and 0.12 on 2025-01-15. Upgrades are therefore infrequent and the format is stable, which cuts both ways. You will not be chasing breaking changes, and you also will not get new features in the C tool, since the README directs those to minizign. The licence is ISC, a permissive licence functionally similar to MIT and BSD: it permits use, modification and redistribution with the copyright notice and permission notice retained. The README does not describe trademark terms or any patent grant, so if your legal review needs those, the LICENSE file is the source to read. Nothing here is legal advice. The practical implication for adopters is that embedding the format in a commercial product carries no copyleft obligation under ISC, but the compatibility claim with signify and the various reimplementations mean you should verify the specific library you embed against the signature files you actually receive.

## Conclusion

Adopt Minisign if you publish tarballs or binaries and want a signature file that fits in one line of a download page, or if you need to verify a project that already ships .minisig files. Do not adopt it if you need key revocation, expiry, web of trust, or a keyring that survives a compromised laptop; GPG or a transparency-log system covers those and Minisign does not. Before relying on it, check which artifact you are actually running: the README states that minizign is now the recommended implementation and that new features go there, so verify whether the C tool still receives the changes you need, and confirm your platform has a package or that you can build from source with Zig 0.15.1 or later or with CMake and libsodium.

## FAQ

### What is Minisign used for?

It signs files and verifies digital signatures using the Ed25519 public-key signature system, producing a detached .minisig file next to the signed file. The README describes it as simple, secure, minimal and cross-platform, and its signatures are compatible with OpenBSD's signify.

### How do I use Minisign to sign and verify a file?

Generate a key pair with minisign -G, sign with minisign -S -m file.txt, and verify with minisign -Vm file.txt -p minisign.pub. The README also allows passing the public key directly with -P instead of a key file.

### Is there a Minisign alternative?

GPG covers the same signing job with key expiry, revocation and a web of trust, none of which Minisign documents. The README also lists minizign, a Zig implementation it now recommends for new features, alongside rsign2, go-minisign, rust-minisign and py-minisign.

## Sources

- [jedisct1/minisign on GitHub](https://github.com/jedisct1/minisign)
- [License: ISC](https://github.com/jedisct1/minisign/blob/master/LICENSE)
- [Project website](https://jedisct1.github.io/minisign/)
- [README](https://github.com/jedisct1/minisign/blob/master/README.md)
- [Releases](https://github.com/jedisct1/minisign/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jedisct1-minisign