Signed releases

[dzwdz]

Hi, I can't find signatures for the release tarballs. Assuming this isn't a PEBKAC - is not signing them an intentional choice?

I do think people should audit the code instead of trusting it basing on its author - I assume you think the same - but even if I do read the code, some additional assurance is always nice.

[LoupVaillant]

is not signing them an intentional choice?

Laziness more than anything, to be honest. I don’t even maintain a public key chain right now.

some additional assurance is always nice.

I’m not sure under what threat model a signature would make things more reliable… Right now I’m relying on GitHub and Gandi to faithfully serve the binaries I want them to serve, and TLS between you and them to make sure you get what they serve. I could sign them on top, but I’m not sure what good it would do: I’d have to distribute my public key somehow, and most likely that would be…GitHub and Gandi. So if they get hacked or start behaving evil, they could easily swap my public key with one under their control, and your verification would still say "OK".

The only way this would do anything, would be if not only I maintain a long term public key, but my users store it too. They’d have to trust the key on first use anyway. And right now, you could do almost as good, by simply hashing my released tarballs: if you download the same version twice, and you get different tarballs, something is going on.

I could sign my releases, but to be honest right now it feels like security theatre. But if I missed something, or if there’s a way to add meaningful security with signatures, I’m honestly interested. Any thought?

[dzwdz]

And right now, you could do almost as good, by simply hashing my released tarballs: if you download the same version twice, and you get different tarballs, something is going on.

That doesn't work for updates.

I’d have to distribute my public key somehow, and most likely that would be…GitHub and Gandi.

I could sign my releases, but to be honest right now it feels like security theatre. But if I missed something, or if there’s a way to add meaningful security with signatures, I’m honestly interested. Any thought?

First off - I have no idea how the web of trust works, or how any of this stuff is "conventionally" handled within the PGP ecosystem. However, when I get signed tarballs (which I prefer), I can verify the keys via some of the following:

• Distro packages - Debian, Arch, etc. tend to include the signing key in the packaging repo (e.g. see the libotr key in Debian and Arch).
  • that's probably the most frequent way I cross-reference keys for software
  • even if the distro just does TOFU - if the key has been there for several years, and has been used for multiple releases, that's a decent sign the key is probably legit (barring a massive fuck-up by the maintainers, or the download site being compromised for a few years straight)
• archive.md/web.archive.org/similar - which could be useful if monocypher.org got compromised temporarily
• signatures on the key
  • Notable example: Tails expert instructions have you verify their signing key via signatures from a few keys in the Debian keyring, which you can get from apt.
    • If you know any Debian/Arch/etc devs who would be willing to sign your key, I could have a direct trust path from my distro to you.
  • I've also e.g. verified the deb.torproject.org signing key recently via a signature from Roger Dingledine, whose key I had "enough" trust in via the other methods here.
  • Not necessary for the other methods to work.
• Social media - for example, I have my key on my lobste.rs profile, and even libera.chat (which you can see via keyoxide).
  • (note that I can use archive.md for most of these too)
• If all else fails... googling. Maybe I can find the key in a location that I deem trustworthy, that I haven't considered before. That's how I figured out I can use the keys distros use for packaging.

Apart from getting your key signed by someone in a distro keyring, none of these methods are that good on their own, but each lets me gain some extra confidence in the key, even if I can't verify it fully.

Also, as mentioned - from the perspective of distro packaging I do think that even TOFU is an improvement over trusting the download sites with each update.

[LoupVaillant]

Okay, you make good points. I’ll set this up.

the PGP ecosystem.

Err… no, I’m not going to use PGP. I’ll start with Ed25519, and see how it can be serialised. Also, I have a TKey, I might as well put it to good use, reduce the likelihood of a compromise. (Aaaand, now I have practical incentive to confirm or disprove that this little trick works.)

[dzwdz]

Hm. It doesn't seem like Debian's packaging tools support non-PGP signatures from upstream yet (#980233 "uscan: please allow for non-GPG signature verification mechanisms").

There's work being done to add support for that, but I think it's being done in private right now. I don't know if uscan is just going to get support for e.g. signify, or if it's getting more generic support for signature verification. You did mention Minisign in that reddit thread, and their site says it's (partially) compatible with signify¹, so I guess it's fine either way.

Right now packages such as OpenSSH and OpenBGPD seem to be signed with both signify and PGP, and Debian checks the latter signature. Not using PGP also means most of these janky key verification methods don't work anymore, but I suppose you could view that as a positive :p

Sidenotes:

• I was told that if "I have the energy to push [that uscan bug], it would be great". I guess this means I'll bump it saying that there's an upstream that
• Also, sorry for the double Cc on that debian email. I'm not very good with computers.

Footnotes

1. ...except that doesn't seem to be true? Minisign now does signatures prehashed with BLAKE2b (which I guess also means you might be able to get away with regular Ed25519?), and they're threatening to remove support for the "legacy" raw signatures (which seem to be the only ones signify supports). ↩

[fscoto]

I'm chirping in late but figured I ought to give a few miscellaneous thoughts regardless:

From my understanding, the threat model for signed releases involves either a compromise of the distribution site, the user's connection to the distribution site (MitM in collaboration with an ISP/public wi-fi/some random certificate authority that happily mis-issues certificates) or the maintainer's access credentials to the distribution site. The distribution sites in this case are GitHub (tagged release) and the monocypher.org website. To my knowledge, there are no (officially sanctioned) mirrors. The mitigation with signed releases involves that users or downstream distributors get a trustworthy cryptographic identity ahead of time of compromise. The mitigation with "just read the code, it's 2000 lines of mostly straightforward C if you ignore the signing stuff" seems to me unrealistic for transitive users, namely consumers of bindings and dependents of dependencies that depend themselves on Monocypher.

Let's look at some tooling for Monocypher's downstreams. I'll take a look at Linux distributions and similar OS-level packaging facilities specifically because ensuring clean initial upstream packages is a significant selling point. Bindings tend to either trust the Linux distributions or vendor Monocypher anyway. Fedora's monocypher and monocypher-devel packages use RPM infrastructure. Checking OpenPGP signatures from upstream is part of standard RPM tooling and mandated by Fedora. As for the Debian side of things, @dzwdz already did the research. Void Linux has their own XBPS package format. XBPS suggested adopting signify, but this ultimately seems to have gone stale (void-linux/void-packages#28400); as far as I can tell, there's no support for PGP signature verification, either.

OpenPGP is, for better or worse, the standard. RFC 9580 § 9.1. at least mandates that any implementations of OpenPGP following the current RFC must implement Ed25519 for signatures (as the sole required signature algorithm). It's still full of cruft. But the tooling in the Linux packaging world supports it. I believe it may be worthwhile to put up with OpenPGP in this instance. I obviously agree with the idea of a secure hardware element to hold the key. Though it would be a nice added feature the generation and storage on the secure hardware element could be attested. I couldn't find out with reasonable time if TKey supports that.

In my opinion, OpenBSD's signify or its reimplementation née compatible port Minisign would indeed be more in line with Monocypher's whole design philosophy. If Minisign were to remove “legacy” signatures, they'd create incompatibility with OpenBSD signify. I suspect that would be interesting but not really enjoyable for anyone in the ecosystem, so I'd personally even speculate that the removal ultimately never will arrive.

There's also Sigstore, which ties directly into GitHub accounts and releases to make it as frictionless and easy to adopt as possible. It is also unfortunately rather complex and, at a glance, intended use are language package managers rather than standalone releases.

Another point to think about is signaling. I know, Loup, you're not big on status signaling. But not having signed releases for a cryptography library may be taken as a failure to send an expected signal, i.e. failing to meet even table stakes.

[LoupVaillant]

Okay, looks like we’re signing.

OpenPGP is, for better or worse, the standard.

I don’t really want to put up with the cruft (especially ASN.1), but since this is an output, and not an input, I might be able to shortcut this into a relatively simple program. First though, I think I’ll start with Signify. The output format is a separate problem from the signature itself, and I’d like to get that part right (I don’t want my key to be compromised of course, but I don’t want the loss of my TKey to mean the loss of my private key either).

Though it would be a nice added feature the generation and storage on the secure hardware element could be attested. I couldn't find out with reasonable time if TKey supports that.

It can’t, for two reasons:

1. It’s not implemented in the first place. Tillitis provides a way for users to know if the key is genuine, but that only works for the verification program. Different programs have access to different (and unrelated) secret keys, none of which are attested. I guess they could do that, but then only a very small set of officially sanctioned program would be attested, destroying the flexibility that’s the main appeal of the TKey.
2. I want my private key to survive the loss of my TKey, so I can’t keep it there. I’ll have to generate it some other way, then store that master copy somewhere secure I’ll practically never access. Perhaps even an encrypted piece of paper. What I need regular access to can be a TKey encrypted copy, where losing the TKey means losing access to that particular copy. In any case, no attestation there too.

So I’m afraid you’ll all have to trust me when I pinky promise I’m using Some Super Secure Signing Scheme for my releases.

Another point to think about is signaling. I know, Loup, you're not big on status signaling. But not having signed releases for a cryptography library may be taken as a failure to send an expected signal, i.e. failing to meet even table stakes.

Yeah, I still remember the tweet mocking Monocypher because my personal blog was still on plain HTTP. Nevermind the fact that monocypher.org itself was on HTTPS from the start.

More current, I’ve recently been contacted about my plans for vulnerability disclosures: turns out the total lack of CVE for Monocypher is a cause for concern. I can promise I will publish any future vulnerability in whatever turns out to be the most popular database of the year, but I really really don’t want to register in advance. Though I suspect this may be required for people to have automatic notifications, especially the transitive users you spoke of. And to be honest, I think compiler or micro-architecture induce vulnerabilities are getting more probable than actual flaws at this point. If all of a sudden Clang decides to turn my constant time lookups into exploitable "let’s query signatures and infer the private key from timings" vulnerabilities, I’m not sure it should even count as a CVE. And yet, users need to know about that stuff.

Another thing that’s I think is starting to send negative signals, is the lack of new releases. The project probably looks stale, while in fact it is mostly finished. That’s supposed to be good!