[tahoe-dev] survey on side-channel attacks

[Zooko O'Whielacronx]

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):
http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html

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!

Regards,

Zooko

[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