
Impact of SKS Keyserver Poisoning on Gentoo - zach43
https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html
======
dngray
One of the things that surprises me is the TorProject still uses SKS in their
documentation. They don't make their keys available any other way or have
their own key server [https://support.torproject.org/tbb/how-to-verify-
signature/](https://support.torproject.org/tbb/how-to-verify-signature/)

> _If you are looking for them, you may try keys.openpgp.org keyserver that is
> not vulnerable to the attack, at the cost of stripping all signatures and
> unverified UIDs._

I have also been unable to get keys.openpgp.org to work For example:

    
    
        gpg --keyserver hkp://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion --recv-keys 0x4E2C6E8793298290
        gpg: key 0x4E2C6E8793298290: no user ID
        gpg: Total number processed: 1
    

They talk about that here:

[https://keys.openpgp.org/about/faq#older-
gnupg](https://keys.openpgp.org/about/faq#older-gnupg)

I'm on Archlinux, my gnupg is 2.2.16, libgcrypt 1.8.4 which are currently the
the latest
[https://gnupg.org/download/index.html](https://gnupg.org/download/index.html)

------
exabrial
I discovered a similar bug awhile back in an important piece of software and
sent it on to get fixed. Essentially the gpg implementation always assumed the
signatures on the key would be rsa, so merely signing someone else's key with
an ecdsa key would block them from using said thing. I had discovered it by
accidently doing it to myself

