PGP Key Poisoner
Peter Lebbing
peter at digitalbrains.com
Tue Aug 13 14:09:53 CEST 2019
I suspect we haven't seen this issue being done in the real world before
because it is not a useful attack in many scenarios. It's just a nasty
DoS that can be avoided by not using the SKS keyserver network. I'm
completely speculating, but I think that the people who really want to
learn something about their victim will use and have used completely
different attacks. This DoS isn't effective at what they want.
I don't know if that is the case, but I think it's a possibility.
This doesn't mean that this attack was harmless; far from it. I think it
has the potential to do a lot of harm to a lot of people. It just
possibly doesn't really accomplish the goals that, for instance,
oppressive regimes or black hats penetrating networks have. And since no
serious attacker used this weakness, by that virtue it might not be a
big problem. The good sides of the SKS keyserver network might outway
its flaws when the flaws are not the flaws that attackers will exploit
in practice.
Until little boys with matches come round and play at being responsible
security researchers without understanding how that actually works.
> People know there that there are issues for a decade with the software
> running on their servers and they don't understand the codebase to fix
> issues.
I don't think the bit about the OCaml code complexity was a good
argument in Rob's gist post.
I think the proper fix is to design an alternative to the SKS keyserver
network. The design choices in the reconciliation protocol don't work
out anymore, we shouldn't change the protocol but replace it.
Several alternatives for key distribution have actually been developed
for many years now. You can't say people are not actively working on
this problem, it's just not true. That they are actually looking in a
different solution space than what you want to see is their right.
> And when things later happen, like recently, they still run their
> servers.
Perhaps because there are still users who need it. GnuPG 2.2.17 already
led to a report[1] on the mailing list that they needed third-party
signatures from keyservers. I don't know if they need the SKS network,
but in general, there are users out there who can still use it.
But I obviously can't speak for anyone else.
> I wonder why those SKS key servers are so important to be still in
> service as of today since we have WKD, Hagrid, keybase, Mailvelope Key
> Server and Facebook?
Only people using the SKS keyserver network are affected by this issue.
You say you don't see a reason to use them. So don't. Tell your
correspondants to use different methods when they exchange keys with
you, and you'll never have to interact with the SKS keyserver network
again. Problem solved; for you. Others will take care of their own.
Also.... Facebook?
A lot of the alternatives to the SKS network have some issues regarding
either a form of trusted third party, or of anonymity. Every service has
its own trade-offs. And some stand out like a sore thumb. Again...
Facebook?! :-)
Cheers,
Peter.
[1] <https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062359.html>
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190813/d540975d/attachment.sig>
More information about the Gnupg-users
mailing list