Comments on: Side channel attacks on cryptographic software http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/ Embedded security, crypto, software protection Thu, 09 Sep 2010 12:45:32 +0000 hourly 1 http://wordpress.com/ By: Nate Lawson http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/#comment-5486 Nate Lawson Wed, 06 Jan 2010 19:36:06 +0000 http://rdist.root.org/?p=487#comment-5486 Well, your comment keeps hitting my spam filter due to the length of the URL. But anyway, no reason to waste time on this. :) Well, your comment keeps hitting my spam filter due to the length of the URL. But anyway, no reason to waste time on this. :)

]]> By: Nate Lawson http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/#comment-5484 Nate Lawson Wed, 06 Jan 2010 19:31:19 +0000 http://rdist.root.org/?p=487#comment-5484 Byron, you are correct. That is a mistake in the article. It should read "128-bit authenticator". Thanks for pointing it out. Byron, you are correct. That is a mistake in the article. It should read “128-bit authenticator”. Thanks for pointing it out.

]]> By: Zooko http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/#comment-5483 Zooko Tue, 05 Jan 2010 17:18:55 +0000 http://rdist.root.org/?p=487#comment-5483 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 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

]]> By: Byron Thomas http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/#comment-5482 Byron Thomas Tue, 05 Jan 2010 16:25:11 +0000 http://rdist.root.org/?p=487#comment-5482 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? 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?

]]> By: Nate Lawson http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/#comment-5480 Nate Lawson Tue, 05 Jan 2010 00:37:48 +0000 http://rdist.root.org/?p=487#comment-5480 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 <a href="http://homes.esat.kuleuven.be/~ekasper/papers/aes_speedcc09_slides.pdf" rel="nofollow">bitsliced AES</a> 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. 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.

]]> By: Zooko http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/#comment-5477 Zooko Mon, 04 Jan 2010 23:22:12 +0000 http://rdist.root.org/?p=487#comment-5477 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 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

]]>