Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Transparent Keyserver

words.filippo.io

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Building a Transparent Keyserver

#21

Post by upofadown »

FiloSottile wrote: post #13
upofadown wrote: post #11

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 no…

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.

A single SKS server can not serve a fake key, only a valid key that existed in the past. This might be done to maliciously unrevoke a key. The normal PGP key integrity prevents straight up forgeries.

Re: Building a Transparent Keyserver

#22

Post by dctoedt »

notyourancilla wrote: post #4

> 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

> [GIF has a hard G]

Glad I preserved a tweet that commented on a subheadline at The Verge from when the creator of the GIF died:

Subheadline from The Verge: "It's pronounced 'jif'"

Tweet: "I guess he's with jod now"

https://toedtclassnotes.site44.com/#orgdf3fc45

Re: Building a Transparent Keyserver

#24

Post by FiloSottile »

miki123211 wrote: post #23

As a monitor, how do you differentiate between the operator removing a poisoned key versus them adding a malicious key and then trying to hide that fact?

You don’t, but remember you monitor your own keys: if you know you didn’t upload a poisoned key and the log refuses to serve a key preimage for your email, you’ve caught it misbehaving.

Re: Building a Transparent Keyserver

#25

Post by akerl_ »

some_furry wrote: post #20
Thom2000 wrote: post #17

Earlier quoted context omitted.

> PGP supports RSA. That's enough reason to avoid it. I hate to break the narrative but age also supports RSA, for SSH compat: https://man.archlinux.org/man/age.1#SSH_keys

That's only because SSH supports RSA. Mainstream usage of age with age public keys only supports X25519.

Eh. You don't really get to do this sleight of hand. If you're gonna rag on RSA support as a shibboleth for bad design, it's bad for GPG and bad for age. If it's direct evidence of bad design, age shouldn't have permitted it via their SSH key support.

Re: Building a Transparent Keyserver

#26

Post by some_furry »

akerl_ wrote: post #25
some_furry wrote: post #20

Earlier quoted context omitted.

That's only because SSH supports RSA. Mainstream usage of age with age public keys only supports X25519.

Eh. You don't really get to do this sleight of hand. If you're gonna rag on RSA support as a shibboleth for bad design, it's bad for GPG and bad for age. If it's direct evidence of bad design, age shouldn't have permitted it via their SSH key support.

I agree in principle, but I'm not looking at "what SSH dragged in". I'm looking at age as a pure isolated thing, according to the spec: https://github.com/C2SP/C2SP/blob/main/age.md

This transparency keyserver actually gives us an excellent opportunity to measure how many people use Curve25519 vs RSA, even with SSH support.

We should contrast this with actively valid public keys on a PGP keyserver in 2026 and see which uses modern crypto more. The results probably won't be surprising ;)

Re: Building a Transparent Keyserver

#27

Post by akerl_ »

some_furry wrote: post #26
akerl_ wrote: post #25

Earlier quoted context omitted.

Eh. You don't really get to do this sleight of hand. If you're gonna rag on RSA support as a shibboleth for bad design, it's bad for GPG and bad for age. If it's direct evidence of bad design, age shouldn't have permitted it via their SSH key support.

I agree in principle, but I'm not looking at "what SSH dragged in". I'm looking at age as a pure isolated thing, according to the spec: https://github.com/C2SP/C2SP/blob/main/age.md This transparency keyserver actually gives us an excellent opportunity to measure how many people use Curve25519 vs RSA, even with SSH support. We should contrast this with actively valid public keys on a PGP keyserver in 2026 and see whi…

Those goalposts are really agile.

We've moved from "PGP supports RSA. That's enough reason to avoid it." to "We should contrast this with actively valid public keys on a PGP keyserver in 2026 and see which uses modern crypto more".

Re: Building a Transparent Keyserver

#28

Post by some_furry »

akerl_ wrote: post #27
some_furry wrote: post #26

Earlier quoted context omitted.

I agree in principle, but I'm not looking at "what SSH dragged in". I'm looking at age as a pure isolated thing, according to the spec: https://github.com/C2SP/C2SP/blob/main/age.md This transparency keyserver actually gives us an excellent opportunity to measure how many people use Curve25519 vs RSA, even with SSH support. We should contrast this with actively valid public keys on a PGP keyserver in 2026 and see whi…

Those goalposts are really agile. We've moved from "PGP supports RSA. That's enough reason to avoid it." to "We should contrast this with actively valid public keys on a PGP keyserver in 2026 and see which uses modern crypto more".

We aren't having the same discussion in both places, so no, it's not a fucking goalpost.
Post reply on HN