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=...
If you have questions I'll try to answer them
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).
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.
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.
The attacks themselves aren't new. Years ago there was somebody duplicating large connected sets of keys.
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... and just implement everything that doesn't seem like a big brother suggestion.
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.
> https://www.thalesesecurity.com/products/key-management/inte...
