Hacker Newsnew | comments | show | ask | jobs | submit | asciilifeform's comments login

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?

> Still think it was 'cosmic rays' on SKS's machines?

Just FYI, this kind of stuff seems to have been done before, with vulnerable keys found:

https://eprint.iacr.org/2012/064.pdf (2012),


(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

You are just the man to expose the sham, perhaps?

Where did we cheat? Who and why placed the key on SKS? Or is Mircea's pact with Satan spiffy enough to enable him to alter the laws of arithmetic?

I, for one, would still like to learn who and why placed the garbage on the SKS servers. (And no, I cannot prove to the satisfaction of everyone that I had not somehow done it myself. Though if anyone can picture what such proof would look like, I'd be happy to try.)

And why Mr. Anvin's key was chosen, rather than another.

I don't find that especially interesting.

If the design of the keyservers is such that they'll accept untrusted info and will relay it expecting clients to verify it, we shouldn't be surprised when we find bogus data on the keyservers.

We should be surprised if the clients do something other than reject the bogus data, but so far we're seeing them do the right thing.

Incidentally, anyone who suspects that I, Mircea, or Hitler fabricated these keys in order to troll the planet, is free to contact anyone who runs an SKS mirror and ask to examine their copies.

I do not know where the key came from, and especially whether it originates from the person who it claims to belong to (other people have found persuasive evidence that this is not the case) but I did find them 'in the wild.' Doubters are encouraged to check for themselves.

The key as seen by Phuctor had three sub-keys, one of which was an RSA key which turned out to be factorable.

Sorry, I was looking at the other one. But something is still very, very odd. (1) Two of the subkeys agree with one another for hundreds of digits and then disagree. (2) I did gpg --recv-key 51221121 and I got a key back from the keyserver with fingerprint 7EAA C969 3E7D 2205 46BE 576C BDA0 6085 493B ACE4 (only, no other keys) -- which doesn't match the key ID that it should, and is seemingly missing the vulnerable subkey entirely.

Can you post the ASCII-armored key that you have? I am getting a radically different key from the keyservers, and I wonder if there could be some kind of keyserver attack or misbehavior involved here too.

Author of 'phuctor' speaking.

I can only confirm that we have a key, downloaded from an SKS dump, said key purporting to belong to one Mr. Anvin, containing one sub-key being an RSA public key which turned out to be factorable with trivial effort.

Anything else is mere conjecture.

Author of 'phuctor' speaking. We did not break RSA! Please put that Luger down, unload it. You have things to live for!

We only found (at the time of this writing) two sets of two poor buggers each who happened to have generated RSA keys having a common factor.

Is the origin of the keys and why they're broken in this way known? Perhaps they were generated on embedded devices and their demise could be traced back to an early boot time entropy problem.

Not known to me.

Author of the linked article speaking.

Possibly I should have emphasized the specific claim that junky input devices (e.g. QWERTY keyboard) are merely one symptom of the deprofessionalization of computer programming - rather than the 'alpha and omega' of it.

And, in this case, not only of computer programming. The fact that millions of people who make their living entering natural language text do so with the abominable limb destroyer known as QWERTY is an atrocity. Quite like the case of the radium watch dials and the labourers who went to an early grave making them. Or those who worked in the match factories, before them.


I just read through what you had to say about the death of HyperCard.

Why do you think Python etc. do not fill the hole HyperCard has left? Is it because of their ever-so-slight price of admission (which tends to push non-professional users away, as compared to the comfortable familiarity of a GUI)?


Which Python? Ver. 2 or 3? On what machine? With what graphical libraries? How much study would be involved in knowing all (and yes, it matters) of the Python+libs+os aggregate?

And does anyone alive know the above aggregate the way a kid can know Hypercard?

The 'master of all you survey' feeling of a kid on a raw Commodore-64 (or, to a lesser extent, Hypercard) - matters. If you've never experienced it, you are a blind man.

Asking the question re: Python suggests precisely this kind of blindness.

I confess that I do not know how to explain sight to a blind man. Perhaps someone else here is up to the task.


You need an air-gapped computer. An old (circa 2000 or so) laptop running some unix-like is probably best.

I'm involved in a project to produce a cheap hardware widget to make this kind of thing easier (http://cryptome.org/2013/10/bitcoin-usb-gpg.htm) but it is not yet in production.


The original (in BASIC!) - http://www.loper-os.org/bad-at-entropy/GD.BAS



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact