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.
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).
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).
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.
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.
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... and just implement everything that doesn't seem like a big brother suggestion.
14 comments
[ 3.0 ms ] story [ 16.7 ms ] threadThe 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.
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
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).
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.
https://saltpack.org/
The attacks themselves aren't new. Years ago there was somebody duplicating large connected sets of keys.
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...
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.