3 ms·
I'm almost certain this news is wrong. I know that because I made the same mistake a while ago. Luckily for me I didn't publish it, but I already had written ma
by hannob 11y ago
I'm almost certain this news is wrong. I know that because I made the same mistake a while ago. Luckily for me I didn't publish it, but I already had written mails to a number of people (including hpa) warning them of a compromised key (which was a false alarm).
Here's what's going on: There are a number of keys on the keyservers that are faulty copies of real keys - they share most of the values, but have some errors. I don't exactly know why that is happening, but I assume it's because of network transmission errors or server crashes during transmissions.
These keys don't really do any harm. GPG will refuse to import them because of the faulty self-signature. So nobody will ever encrypt with those keys.
A Batch GCD attack on the PGP keyserver set has already been done a while ago by Lenstra and again by me recently. If you replicate this you'll find two old broken keys with unknown origin. These seem to be the only vulnerable ones, but they're expired. You'll find one key which looks like a test by someone and a large number of those broken keys with small factors.
I wrote a paper about my findings:
https://eprint.iacr.org/2015/262 https://eprint.iacr.org/2015/262
Also some code:
https://github.com/hannob/pgpecosystem https://github.com/hannob/pgpecosystem
And if you want to replicate the batch GCD attack Nadia Heninger has released source code for this:
https://factorable.net/resources.html https://factorable.net/resources.html
- asciilifeform 11y agoIt remains to be seen whether 'These keys don't really do any harm.' And good job repeating my research without any acknowledgment. Does your sponsor know about Phuctor? What if he were to read this thread?
- diafygi 11y agoThe factored keypair in question is actually a subkey on HPA's public key. However, it appears that the self signature (which is a signature on the hash of the main public key and the subkey) does not match the hash_check. The issuer of this self signature has the same key_id as HPA's main key, which is why this subkey is listed under HPA's public key. Here's a json breakdown of the invalid hash_check: https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-hpa-pub-json-L490 https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-... EDIT: It's the EXACT SAME subkey self-signature packet as HPA's real subkey self-signature packet! Someone (by malice or mistake) manually added a subkey to HPA's public key and copied the signature from the other subkey directly onto the new subkey. These are the same: Bad subkey self-signature: https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-hpa-pub-json-L498 https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-... Good subkey self-signature: https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-hpa-pub-json-L566 https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-...
- zmanian 11y agoHere is Nadia H's lecture at Stanford from last week. Covers the GCD batch attack and her hypothesis about where the weak RSA keys are coming from. https://mvideos.stanford.edu/graduate#/SeminarDetail/Spring/2015/EE/380/9469 https://mvideos.stanford.edu/graduate#/SeminarDetail/Spring/...
- undata 11y agoWhat do you make of this? https://news.ycombinator.com/item?id=9575598 https://news.ycombinator.com/item?id=9575598