Building a Transparent Keyserver

46 pointsposted 6 hours ago
by noident
(words.filippo.io)

16 Comments

agwa

27 minutes ago

There are a couple things missing from this:

1. The monitoring client does not ensure that the checkpoint was created recently, so a malicious log can conceal malicious entries from monitors by serving an old checkpoint.

2. Though the age keyserver policy is not configured this way, the post suggests you could create a policy that requires only a minority of witnesses (e.g. 3 of 10) to cosign a checkpoint. If you do this, then monitors have to get checkpoints that are cosigned by at least 8 of the 10 witnesses. Otherwise, a malicious log could present one view to relying parties that is cosigned by one set of witnesses, and a different view to monitors that is cosigned by a different set of witnesses. There is currently no mechanism specified for monitors to get these extra cosignatures, so if you go with a minority policy you'll need to invent your own stuff in order for witnessing to actually accomplish anything.

sublimefire

3 hours ago

Dunno, IMO you need to know the bits of what operator is running to fully trust the third party, eg run in an enclave and share attestation evidence and the source code. Otherwise, operator can just mimic the appearance of the log.

FiloSottile

3 hours ago

No, the point of the Merkle tree inclusion proofs and of the witness cosignatures is precisely that the operator can't show a different view of the log to different parties.

Thom2000

5 hours ago

I wonder if they think of a deeper integration of this into the age binary. Currently the invocation looks extremely ugly:

    age -r $(go run filippo.io/torchwood/cmd/age-keylookup@main joe@example.com)

akerl_

5 hours ago

I assume once it's stabilized you'd swap the `go run` for just installing and using a binary, similar to what you're already doing with age.

FiloSottile

4 hours ago

Honestly not sure why I didn't do that once the tool had stabilized.

Switched to

    go install filippo.io/torchwood/cmd/age-keylookup@main
    age -r $(age-keylookup alice@example.com)
age is designed to be composable and very stable, and this shell combination works well enough, so it's unlikely we'll build it straight into age(1).

Imustaskforhelp

3 hours ago

Offtopic but I really appreciate golang and so I am always on the lookout of modern alternatives and I found age and I found it to be brilliant for what its worth

But I was discussing it with some techies once and someone mentioned to me that it had less entropy (I think they mentioned 256 bits of entropy) whereas they wanted 512 bits of entropy which pgp supported

I can be wrong about what exactly they talked about since it was long time ago so pardon me if thats the case, but are there any "issues" that you know about in age?

Another thing regarding the transparent servers is that what really happens if the servers go down, do you have any thoughts of having fediverse-alike capabilities perhaps? And also are there any issues/limitations of the transparent keyserver that you wish to discuss

Also your work on age has been phenomenal so thank you for creating a tool like age!

some_furry

2 hours ago

> But I was discussing it with some techies once and someone mentioned to me that it had less entropy (I think they mentioned 256 bits of entropy) whereas they wanted 512 bits of entropy which pgp supported

> I can be wrong about what exactly they talked about since it was long time ago so pardon me if thats the case, but are there any "issues" that you know about in age?

Entropy bikeshedding is very popular for PGP / GnuPG enthusiasts, but it's silly.

age uses X25519, HKDF-SHA256, ChaCha20, and Poly1305. Soon it will also use ML-KEM-768 (post-quantum crypto!). This is all very secure crypto. If a quantum computer turns out to be infeasible to build on Earth, I predict none of these algorithms will be broken in our lifetime.

PGP supports RSA. That's enough reason to avoid it.

https://blog.trailofbits.com/2019/07/08/fuck-rsa/

If you want more reasons:

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

notyourancilla

5 hours ago

> The author pronounces it [aɡe̞] with a hard g, like GIF, and is always spelled lowercase.

Of all the words we could've used to explain how to pronounce something

tptacek

4 hours ago

It's pronounced "aggie".

noident

6 hours ago

Filippo Valsorda discusses his server for storing age keys

xeonmc

5 hours ago

At first glance I misread this as "stone age keys" and thought it was a dig at gpg

upofadown

3 hours ago

The good old SKS network achieves most or all of the advantages of key transparency in a simpler way by being append-only. An attacker could downgrade your PGP identity on one server but the rest would have the newest version you uploaded to the network.

There was a theory floating around back in 2018 that the append-only nature of the SKS network makes it effectively illegal due to the GDPR "right to erasure" but nothing came of that and the SKS network is still alive:

* https://spider.pgpkeys.eu/

FiloSottile

3 hours ago

The SKS network is append-only in aspiration. There is nothing like a Merkle tree stopping a server in the pool (or a MitM) from serving a fake key to a client. The whole point of tlogs is holding systems like that accountable. Also, the section on VRFs of the article addresses precisely the user removal issue.