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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
