skip to content W3C SVG

Signify

In 2014, Ted Unangst wrote signify, a tool to cryptographically verify OpenBSD’s artifacts: releases, packages (via pkg_add), patches, …

It only supports a single algorithm, Ed25519, created by djb and his gang. It’s fast, immune to timing attacks by design, produce deterministic signatures, uses small keys and produce small signatures, … it does look like a sound choice.

The key distribution and rotation strategy, however, is interesting: The current and next releases’ keys aren’t cross-signed, or signed at all, there is no web of trust, no external trusted path: they are simply stored in /etc/signify. A new key is generated at each release, for the N+2 one, so that it can be embedded in the N+1, creating a trust-path.

Ted Unangst has an explanation about this decision:

There are no key servers for signify. No web of trust. Just keys. The good news is the keys are pretty small. As demonstrated. We can stick them just about everywhere, and we do. They’re on the web site, they’re on twitter, they’re on the top side of CD. 56 base64 characters. You can read it out loud over the phone in under a minute. Wide dispersion makes it harder and harder to intercept all the ways you may get the key and increases the risk of detection should anybody try some funny business.

Unfortunately, it has a couple of shortcomings:

  • If the key for the next release is lost, a trust path would have to be reestablished from scratch
  • There is no revocation mechanism, if the key is stolen, all what OpenBSD can do is to tell people that they shouldn’t trust the key anymore. Altought I guess that the OpenBSD people could simply sign a compromise notice with the key.
  • The trust-path can hardly be transitive without relying on other tools: one has to get the key directly from a trusted OpenBSD developer. But on the other hand, as tedu said, since the keys are pretty small, people can plaster them everywhere. Unfortunately, for people that can’t attend various OpenBSD events, living in a place controled by a global adversary, they have no way to bootstrap the trust without relying on something else than signify.

But there are some advantages as well:

  • A small codebase, doing only one thing, while apt is large, meaning more chances of having scary issues.
  • OpenBSD does key rotation for every release.
  • It’s not based on GnuPG.

Amusingly, Debian has a signify package, but it’s a Perl script last updated upstream in 2003, to add some (non-cryptographic) signatures to emails. The right one is of course signify-openbsd, as well as signify-openbsd-keys containing OpenBSD releases’ public keys.