Building a transparent keyserver

Here's an article with a step-by-step guide to implementing transparent logging in Go. I don't see myself ever doing such a thing myself, but it would theoretically be useful if you have a service where people can publish public information and they want to be able to verify that nothing gets published that they didn't write themselves.

There's a central server, but the services watching it to make sure it doesn't misbehave are distributed. There's cryptography involved, but it's not a blockchain; it's something lighter weight than that.

From the article:

Today, we are going to build a keyserver to lookup age public keys. That part is boring. What’s interesting is that we’ll apply the same transparency log technology as the Go Checksum Database to keep the keyserver operator honest and unable to surreptitiously inject malicious keys, while still protecting user privacy and delivering a smooth UX. You can see the final result at keyserver.geomys.org. We’ll build it step-by-step, using modern tooling from the tlog ecosystem, integrating transparency in less than 500 lines.

(Note: 'age' is an obscure encryption tool written by the same author. Looks decent, though?)

If you are familiar with Certificate Transparency, tlogs are derived from CT, but with a few major differences. [...]

In my experience, it’s best not to think about CT when learning about tlogs. A better production example of a tlog is the Go Checksum Database, where Google logs the module name, version, and hash for every module version observed by the Go Modules Proxy. The module fetches happen over regular HTTPS, so there is no publicly-verifiable proof of their authenticity. Instead, the central party appends every observation to the tlog, so that any misbehavior can be caught. The go get command verifies inclusion proofs for every module it downloads, protecting 100% of the ecosystem, without requiring module authors to manage keys.

...

What’s the point of all this though? The point is that anyone can look through the log to make sure the keyserver is not serving unauthorized keys for their email address! Indeed, just like backups are useless without restores and signatures are useless without verification, tlogs are useless without monitoring. That means we need to build tooling to monitor the log.

...

A complete monitoring story would involve 3rd party services that monitor the log for you and email you if new keys are added, like gopherwatch and Source Spotter do for the Go Checksum Database, but the -all flag is a start.

...

Designing the tlog entry is the most important part of deploying a tlog: it needs to include enough information to let monitors isolate all the entries relevant to them, but not enough information to pose privacy or poisoning threats.

...

To get the delayed, collective verification we need, all clients and monitors must see consistent views of the same log, where the log maintains its append-only property. This is called non-equivocation, or split-view protection. In other words, how do we stop the log operator from showing an inclusion proof for log A to a client, and then a different log B to the monitors?

Just like logging without a monitoring story is like signing without verification, logging without a non-equivocation story is just a complicated signature algorithm with no strong transparency properties.

This is the hard part because in the general case you can’t do it alone. Instead, the tlog ecosystem has the concept of witness cosigners: third-party operated services which cosign a checkpoint to attest that it is consistent with all the other checkpoints the witness observed for that log. Clients check these witness cosignatures to get assurance that—unless a quorum of witnesses is colluding with the log—they are not being presented a split-view of the log.