On Mon, 2 Sep 2013 17:44:57 -0400 Jerry Leichter <leich...@lrw.com> wrote: > > ...Clearly, as things like bad vendor drivers updates have been > > sent out using stolen keys in the past, and clearly vendors might > > simply make mistakes in the future.... > > Except that that's not what happened in this case. > > Someone took an old, valid Microsoft license - which should never
Yes, certainly, but the end effect was that an untrustworthy piece of code was then executing on the victim's machine. That can be happen by many means, however, both intentional and accidental -- trojan horses, vendor mistakes, bugs, rogue employees at a vendor, a vendor's credentials being stolen, cryptographic breaks like this, etc. Now, I do indeed find it interesting and exotic that someone involved knows how to create MD5 collisions by a different method than we know of in the open literature, and that tickles my fancy as a person who loves cryptography, and probably tells us something about who wrote that particular exploit. What it does not do, however, is tell me much about how to make systems robust against the wide variety of reasons why untrustworthy software might appear on a machine. As a security person, it is this latter problem that is vital to me, since doubtless that will show up again in the future. Even ignoring malice, bugs often happen in device drivers and other code running in security critical environments like kernels. I will again mumble things like: "typed assembly language, proof carrying code, microkernels, hardware assists, formal verification..." in the hopes that the mumbling might set some minds thinking. Perry -- Perry E. Metzger pe...@piermont.com _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography