And (off-topic) if you are wondering why some of your recent comments are being downvoted so much, it's probably because of the tone (saying things such as "good job repeating my research" when work of the same kind with results of the same kind had been done before (see above.))
Still an interesting result and curious re. SKS servers (not) checking subkeys etc...
Can you please disclose the key ids? Are they the same instances of inserting subkey under someone's public key with an invalid self-signature[1]? If so, it seems that this attack is exploiting the fact that the sks-keyserver pool doesn't verify self-signatures and some non-gpg client might not verify self-signatures either (dunno which one, though).
Comments
Aaaand we found another two. One of which belongs to a GNU dev with some public presence...
Still think it was 'cosmic rays' on SKS's machines? Do cosmic rays preferentially strike public keys belonging to major Open Source figures?
Just FYI, this kind of stuff seems to have been done before, with vulnerable keys found:
https://eprint.iacr.org/2012/064.pdf (2012),
https://factorable.net/
(these two are mentioned and linked to from https://blog.hboeck.de/archives/872-About-the-supposed-facto...)
And (off-topic) if you are wondering why some of your recent comments are being downvoted so much, it's probably because of the tone (saying things such as "good job repeating my research" when work of the same kind with results of the same kind had been done before (see above.))
Still an interesting result and curious re. SKS servers (not) checking subkeys etc...
also https://news.ycombinator.com/item?id=9562170
Can you please disclose the key ids? Are they the same instances of inserting subkey under someone's public key with an invalid self-signature[1]? If so, it seems that this attack is exploiting the fact that the sks-keyserver pool doesn't verify self-signatures and some non-gpg client might not verify self-signatures either (dunno which one, though).
[1]: https://news.ycombinator.com/item?id=9561407