Daemonic Dispatches

My Very Important Response

First, Ptacek now claims that I posted my paper 'months after Osvik and Tromer published what is now "Cache Attacks and Countermeasures: the Case of AES"'. His chronology here is completely wrong: while Shamir famously warned of unspecified dangers inherent in Hyper-Threading in the Cryptographers' Track of RSA 2005 -- some four months after I first discovered this problem -- the Osvik-Shamir-Tromer paper was not written until much later: In fact, a few days after I released my paper (at which point it had been circulating for almost three months with only minor changes) I received an email from Tromer describing their paper as not yet being finished. Of course I didn't cite the work of Osvik and Tromer -- not only had I not yet seen their work, they hadn't even finished writing it! (On the other hand, in the version of my paper which I submitted to the Journal of Cryptology four months later -- by which point the Osvik-Shamir-Tromer paper was published on the web -- I do cite their work and point out the similarities.)

Ptacek goes on to list the reasons he accused me of self-promotion. To respond briefly:

• I will not back down from my argument that servers should be secure by default, with an option available to make them insecure and possibly gain some performance.
• I never attempted to "monopolize attention", and I have always agreed that Bernstein's attack also needed to be addressed.
• I never accused anyone of secretly working for Intel; the closest I ever came to this was a tongue-in-cheek question on a FreeBSD mailing list when someone made (inaccurate) comments which mirrored what Intel's PR people had been saying. However, it is true that Intel attempted to stop me from releasing my paper.
• I never picked a fight with Linus; while I did refer to him as a "dictator", I did so in exactly the same manner as everybody else writing in the area of comparative open source project management.
• If I had been wearing only a cryptographer's hat, I would have gone ahead and submitted my paper to J. Cryptology in March 2006. Instead, I wore two hats: first that of a cryptographer, and second that of a member of the FreeBSD Security Team. The policy of the FreeBSD Security Team is that local privilege escalation and information leakage problems are resolved via security advisories; this policy existed long before I became involved in FreeBSD.

Next Ptacek points out that I have not provided evidence that I did not undertake gainful employment during the period when I was working on this issue. I'm not quite sure what evidence he wants -- my income tax return, perhaps? Does he want a list of the companies which asked me to interview for jobs, and the professors who invited me to apply for post-doctoral research positions? Of course, if I were lying about this I could easily forge such documents, so even if I were prepared to make them publicly available -- which I'm not, for obvious reasons -- it would serve little purpose.

After some floundering concerning side channel attacks -- cryptography which, by his own admission, he doesn't understand -- Ptacek concludes by stating that "any localhost kernel of privilege escalation finding Colin published would be more impactful". In the very narrow sense of FreeBSD security, Ptacek is quite correct here. However, unlike most local kernel privilege escalation attacks, which except in very rare cases only affect a single operating system, the Hyper-Threading side channel I demonstrated affected all SMP i386 operating systems. This wide range of affected systems makes an otherwise less significant issue worthy of more widespread attention; but even without that, the fact that my paper was the first publicly available work which demonstrated the exploitability of the shared L1 cache on Hyper-Threaded processors makes it worth noticing.

While the Blogosphere seems to have taken over from Usenet as the home of "Everybody is entitled to their opinion, even if they're completely wrong", I wish people would make more effort to check their facts before criticizing other people: Incorrect facts make the person posting them look ignorant, while incorrect criticisms tend to make both sides look bad.