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 <a href="https://support.torproject.org/tbb/how-to-verify-signature/" rel="nofollow">https://support.torproject.org/tbb/how-to-verify-signature/</a><p>> <i>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><p>I have also been unable to get keys.openpgp.org to work For example:<p><pre><code> gpg --keyserver hkp://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion --recv-keys 0x4E2C6E8793298290
gpg: key 0x4E2C6E8793298290: no user ID
gpg: Total number processed: 1
</code></pre>
They talk about that here:<p><a href="https://keys.openpgp.org/about/faq#older-gnupg" rel="nofollow">https://keys.openpgp.org/about/faq#older-gnupg</a><p>I'm on Archlinux, my gnupg is 2.2.16, libgcrypt 1.8.4 which are currently the the latest <a href="https://gnupg.org/download/index.html" rel="nofollow">https://gnupg.org/download/index.html</a>
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