Below is a recent article I wrote for IEEE Security and Privacy magazine titled “Side Channel Attacks on Cryptographic Software” (pdf). It covers simple timing attacks against HMAC validation, AES cache timing, and RSA branch prediction attacks. It’s a survey article, covering excellent research in side channel attacks over the past few years.
I think the attacker position is gaining an advantage recently. As CPU microarchitecture gets more complicated, more covert channels appear. Also, the move to virtualization and high-resolution timers gives better quality measurements and more opportunities to exploit even the tiniest of leaks. We’ll need to come up with more clever ways of modeling and eliminating covert channels, moving crypto operations into hardware, and giving software more control over microarchitectural state.
Let me know what you think.
rdist 
Here is what I think: thanks for writing this! It spurred me to reconsider this issue that has been bothering me, and I came up with a new (to me) solution for my decentralized filesystem: combine a timing-attack-resistant cipher like XSalsa20 with AES and make sure that AES doesn’t get to see your master key or your plaintext:
http://allmydata.org/pipermail/tahoe-dev/2010-January/003476.html
Yes, encrypting first with Salsa20 and then with AES would mean your data is safe if the attacker’s only option is a timing attack on AES. But if Salsa20 is weak to another attack, then the attacker can divide and conquer, breaking first AES and then Salsa20, probably by different routes. This is not a vulnerability, just something to keep in mind.
There are two solutions to timing attacks on AES on general-purpose CPUs. I like this bitsliced AES implementation. It requires assembly language but is supported on modern Intel CPUs. Also, it mentions that there will soon be an x86 AES instruction, which will solve this problem in hardware.
P.S. I edited the link in your comment to a shorter version.
But you replaced a link to my blog — http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html — with a link to my mailing list post, which wasn’t what I’d intended. Here is a short URL which redirects to my blog: http://➡.ws/zooko . The reason I give out the long URL instead of the short one is that the ong URL includes a hash of the public key which can be used to check the digital signature on new versions of my blog. It also includes enough information to download the latest version of my blog from a decentralized p2p storage system.
I assume that you dislike it because it is too long and/or too ugly. (If so, you’re not the first!) So I’ve made a note of it on this ticket: http://allmydata.org/trac/tahoe/ticket/217#comment:56 . We need to invent a new crypto scheme which results in shorter URLs.
Regards,
Zooko
Well, your comment keeps hitting my spam filter due to the length of the URL. But anyway, no reason to waste time on this. :)
Nice article Nate.
Just a clarification: I thought the HMAC timing attack (really a comparison timing attack) would only reveal the correct authenticator for a given message, but you state the attacker could “find a 128-bit key in less than a few minutes.” Am I missing something here? Surely finding the key like this is still 128-bit complexity unless you can pre-image attack the hash function?
Byron, you are correct. That is a mistake in the article. It should read “128-bit authenticator”. Thanks for pointing it out.