December 30, 2009

Side channel attacks on cryptographic software

Filed under: Crypto,PC Architecture,Security — Nate Lawson @ 4:00 pm

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.

View this document on Scribd


  1. 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:


    Comment by Zooko — January 4, 2010 @ 3:22 pm

    • 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.

      Comment by Nate Lawson — January 4, 2010 @ 4:37 pm

  2. 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?

    Comment by Byron Thomas — January 5, 2010 @ 8:25 am

    • Byron, you are correct. That is a mistake in the article. It should read “128-bit authenticator”. Thanks for pointing it out.

      Comment by Nate Lawson — January 6, 2010 @ 11:31 am

RSS feed for comments on this post.

Blog at WordPress.com.

%d bloggers like this: