_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Building a Transparent Keyserver
miki123211 wrote 1 hour 41 min ago:
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?
FiloSottile wrote 1 hour 3 min ago:
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.
agwa wrote 4 hours 4 min 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.
FiloSottile wrote 3 hours 37 min ago:
Fixed (1) in [1] , thank you!
I'll add a note to the part of the article that mentions non-majority
policies.
HTML [1]: https://github.com/FiloSottile/torchwood/commit/8b61ef967
sublimefire wrote 6 hours 29 min 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 wrote 6 hours 21 min 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.
upofadown wrote 7 hours 2 min 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:
*
HTML [1]: https://spider.pgpkeys.eu/
FiloSottile wrote 6 hours 30 min 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.
upofadown wrote 2 hours 55 min ago:
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.
Thom2000 wrote 8 hours 30 min 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_ wrote 8 hours 21 min 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 wrote 7 hours 51 min 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 wrote 6 hours 59 min 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 wrote 5 hours 43 min 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. [1] If you
want more reasons:
HTML [1]: https://blog.trailofbits.com/2019/07/08/fuck-rsa/
HTML [2]: https://www.latacora.com/blog/2019/07/16/the-pgp-probl...
Thom2000 wrote 4 hours 19 min ago:
> PGP supports RSA. That's enough reason to avoid it.
I hate to break the narrative but age also supports RSA, for
SSH compat:
HTML [1]: https://man.archlinux.org/man/age.1#SSH_keys
some_furry wrote 3 hours 33 min ago:
That's only because SSH supports RSA. Mainstream usage of
age with age public keys only supports X25519.
akerl_ wrote 48 min ago:
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.
some_furry wrote 12 min ago:
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: [1] 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
;)
HTML [1]: https://github.com/C2SP/C2SP/blob/main/age.md
notyourancilla wrote 8 hours 30 min 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
dctoedt wrote 1 hour 50 min ago:
> [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"
HTML [1]: https://toedtclassnotes.site44.com/#orgdf3fc45
tptacek wrote 7 hours 43 min ago:
It's pronounced "aggie".
FiloSottile wrote 8 hours 0 min ago:
>:)
noident wrote 10 hours 5 min ago:
Filippo Valsorda discusses his server for storing age keys
xeonmc wrote 8 hours 41 min ago:
At first glance I misread this as "stone age keys" and thought it was
a dig at gpg
DIR <- back to front page