[tahoe-dev] survey on side-channel attacks

Zooko O'Whielacronx zookog at gmail.com
Mon Jan 4 14:21:52 PST 2010

Nate Lawson (a good security researcher) wrote a nice article
summarizing side-channel attacks [1].  It includes this discouraging
line: "Unfortunately, owing to the structure of AES, there appears to
be no way to build a high-performance implementation on a
general-purpose CPU while avoiding cache side channels.".  This is why
I want to switch from AES to XSalsa20 [2].  (Also because XSalsa20
uses much less power and/or time [3].) Unfortunately, "AES" is a
successful brand -- it is the only crypto brand that matters and it
appears on all crypto products -- and if we offer our users XSalsa20
instead, even though they will probably be safer, they will probably
think that we are making them less safe.  :-(

I posted this same note on my blog (and posted it to identi.ca which
reposted it to twitter):

Also as my new co-worked Brendan O'Connor reminded me on twitter, US
Gov is required by Federal law not to rely on crypto other than AES.

If the only problem were the potential for algorithmic cracks of AES
then we could solve this problem (at a cost in power and/or time) by
*combining* AES and XSalsa20. Unfortunately, if AES is leaking its
secrets by a timing channel then this won't help.

Oh wait!  Yes, it *could* help.  Encrypt *first* with XSalsa20, *then*
with AES, giving AES a key which cannot be used to figure out the key
that we gave to XSalsa20.  That way even if AES completely divulges
its key *and* its plaintext to the enemy, we're still safe.  Hooray!



[1] http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/
[2] http://cr.yp.to/snuffle.html#security
[3] http://bench.cr.yp.to/results-stream.html

More information about the tahoe-dev mailing list