
Keyservers Are Dying - paule89
https://www.golem.de/news/verschluesselung-aerger-fuer-die-pgp-keyserver-1904-140512.html
======
hannob
I'm the author, didn't expect my German text to end up high on HN.

If you don't speak German Google translate does a good enough job:
[https://translate.google.de/translate?sl=de&tl=en&js=y&prev=...](https://translate.google.de/translate?sl=de&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&edit-
text=&act=url&u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fverschluesselung-aerger-
fuer-die-pgp-keyserver-1904-140512.html)

If you have questions I'll try to answer them

~~~
FabHK
What do you think of Keybase as an attempt at a solution?

[https://keybase.io](https://keybase.io)

Danke!

EDIT to add: Wow, seems like Keybase has pivoted quite a bit from what I
understood it was aiming for in 2013 (a repository of public keys tied
to/verified via social media accounts, with infrastructure to facilitate their
use).

~~~
oconnor663
Former Keybase employee here: Keybase has pivoted quite a bit, but I'd suggest
it still matches your description: a repository of public keys tied
to/verified via social media accounts, with infrastructure to facilitate their
use. The type of the keys has changed; NaCl Ed25519 keys are now heavily
emphasized over PGP keys. And the infrastructure has grown to include both the
proof framework beneath the keys, and user-facing applications built on top of
the keys.

I think one of the big takeaways from the legacy of PGP, is that a public key
system in isolation won't be a successful base for mainstream applications.
Some thoughts on that from the Keybase perspective:

1\. Public key models are difficult to understand. Asking users to learn what
a key is, and then to manage the way their keys interact with multiple
different services, is too much in practice. (Both in terms of adoption, and
in terms of avoiding security mistakes.)

2\. Public key models are difficult to design. The Keybase model is very
different from the PGP model, for example in that it avoids relying on any
single "master key". That's a better fit for users who tend to have many
devices but who tend not to have a great personal backup strategy. This is the
sort of thing that made sense by 2013, but didn't make sense in 1991.

3\. After you design a key system you still need to iterate. Keybase added a
concept of Per-User Keys (shared by all devices, transported using device
keys) while chat was being designed, because it was a better fit for the
security model that chat needed. If Keybase wasn't in control of the key model
and the chat application at the same time, making that change would've been
impractical. There have been many other changes like it -- exploding messages
using ephemeral keys, for example -- and I'm sure there will be more to come.

~~~
w8rbt
I have been looking at saltpack to replace many of my PGP use cases. Has
anyone else?

[https://saltpack.org/](https://saltpack.org/)

------
drenvuk
This is good to know. So in order to prevent the abuse of keyservers and
increase the proliferation of them what should be done?

1\. limit the size of keys (ECC or edd25519 plus hard limits fixes this, yes?)

2\. provide a verified submission for keys and signatures (have users sign
their submissions)

3\. verify email addresses? (i don't care about this one)

4\. disallow old, vulnerable, or insecure keys or cryptographic methods?
(require new crypto as necessary)

5\. Provide new open source key server software entirely? Update the old stuff
because it's still salvageable?

I find it funny as hell that the author is worried about data retention
policies when it's baked into the software and it's explicitly stated in many
places that the keys can't be removed. Maybe I should just read
[https://gitlab.com/dkg/draft-openpgp-abuse-resistant-
keystor...](https://gitlab.com/dkg/draft-openpgp-abuse-resistant-
keystore/blob/master/draft-dkg-openpgp-abuse-resistant-keystore.md) and just
implement everything that doesn't seem like a big brother suggestion.

------
UI_at_80x24
I find it amusingly ironic, that the primary framework for authenticating keys
is inherently untrustworthy. As TFA mentions about 'poisoned keys' are only
part of the problem. I have a key I created in the mid-to-late 90's using a
super-secret-strong-password, and yupp; can't remember it. But it doesn't
matter, because nothing I created or signed back then is worth looking at
again.

BUT that 'fear of re-loss' limits my current usage of PGP/GPG too. I have my
accountant trained to decrypt my attachments and email, and I have my staff
trained to use it too, but it's still a real pain in the ass. I would have
much better faith in a system that I could remotely manage the keyserver for
when I fuck up. Being able to 'reset the password' (maybe use a 2FA style
system) would be nice, but would also make it meaningless.

GPG-As-A-Service ?

If I ever forget my SSH passphrase, I can always generate a new key because I
also have access to the server to accept the new key.

It's turtles all the way down.

------
Tomte
Interesting that people still care enough about PGP key servers to play those
games.

The attacks themselves aren't new. Years ago there was somebody duplicating
large connected sets of keys.

~~~
w8rbt
You can still read about this: [https://evil32.com/](https://evil32.com/)

------
dpflan
Interesting. What updates to enterprise key management exist that are
improving this? Like Thales/Vormetric and Ionic Security.

> [https://www.thalesesecurity.com/products/key-
> management/inte...](https://www.thalesesecurity.com/products/key-
> management/integrated-key-management)

------
kurthr
tldr w/ translation-

The PGP key servers are designed to accept almost anything unchecked. This
leads to numerous problems, most recently the keyservers became more and more
unreliable due to attacks with poisoned keys.

~~~
fixermark
Yep. In short, "Keyservers Are Dying" (because they are a technology with
known exploit vectors that never caught on strongly enough to get the critical
mass of volunteer contributors to patch the issues).

~~~
TheChaplain
What are the known issues that needs corrections? Perhaps it's worth putting
up a bounty for...

