Daemonic Dispatches

My Very Important Knob

The first inaccuracy in his article was to state that I "cribbed" my Hyper-Threading side channel work "directly from Dan Bernstein". In fact, I did nothing of the sort. I first became aware of Bernstein's work in the area of cache-related side channels when he posted to sci.crypt with a URL to his work on cache timing attacks against AES -- work which, at that time, made no mention of Hyper-Threading. In contrast, I had at that point already been investigating the question of Hyper-Threading side channels for weeks. Furthermore, the attack against RSA implementations on Hyper-Threading is very different from Bernstein's attack against AES implementations: Where Bernstein considered the inevitable effects of a cache upon the performance of code, I considered the effects of code upon the cache and how those could be measured.

The second accusation made by Ptacek is that I "went on a blitz of self-promotion". My collecting of vendor responses -- something Ptacek cites as evidence of my self-promotion --- is nothing unusual when coordinating a security advisory affecting multiple operating systems: When CERT coordinates advisories, they always do this. Given the number of people who emailed me to ask if their Windows systems were affected, I wish Microsoft had also provided me with a response.

Ptacek goes on to claim that "there are lots of easy timing side channels if you can run code on the same host as your target". While he correctly points out that a local attacker can often retrieve information about a passphrase being typed by measuring inter-keystroke timings, he makes the entirely unfounded jump from here to concluding that any information can be stolen in the same manner. If Ptacek is really aware of "lots of easy side channels" which can steal RSA keys, I hope he will come forward with details -- for one thing, I'm sure the OpenSSL developers would like to know about them!

Next, Ptacek implies that I, as a single voice, somehow tricked FreeBSD into disabling Hyper-Threading. Perhaps Ptacek hasn't read the papers which he himself is citing: In an updated version of his AES cache timing paper, Dan Bernstein argues that Hyper-Threading should be disabled, while Osvik, Tromer, and Shamir -- who constructed their Hyper-Threading attack against AES completely independently of my work -- came to the same conclusion. On the operating system side, SCO and several Linux distributions followed FreeBSD's lead; from private discussions I know that some other operating systems were planning on doing likewise, but I do not have confirmation that they did so.

At this point, Ptacek points to a recent FreeBSD commit, wherein I changed the default behaviour to allow shared L2 caches -- but still not shared L1 caches -- in order to avoid halving the performance of Intel Core Duo processors. He claims that my paper 'says L2 cache attacks are "potentially interesting"', which is simply untrue. My paper does point out that the L2 cache provides an interesting covert channel, but at no point do I argue that the L2 cache provides a useful side channel, or that any cryptographic information can be stolen using it. I stand by the comment I made in the commit message he quoted: Nobody has publicly demonstrated a cryptographic side channel which exploits the L2 cache.

Finally, Ptacek makes one accurate comment: We need to pursue cryptographic implementations with data-independent timing. (Ok, he's not quite accurate -- what we really need is data-oblivious implementations, not merely implementations with data-independent timing -- but after everything else he has gotten wrong, let's be generous on this point.) Indeed, I have started working on such a cryptographic library; but it takes a long time to build such a library from the ground up, so as I pointed out a year ago, the only approach which could be implemented quickly was to disable Hyper-Threading.