[tahoe-dev] Using a cipher cascade (was: survey on side-channel attacks)

Zooko Wilcox-O'Hearn zooko at zooko.com
Tue Jan 5 07:19:15 UTC 2010

Dear David-Sarah:

I'm happy that you already replied to my idea about the cascade and  
I'm delighted about this:

On Monday, 2010-01-04, at 22:32 , David-Sarah Hopwood wrote:

> I'll take this into account when designing the successor to the Elk  
> Point designs, which will be called Rainhill 3. (Rainhill is where  
> I live. Rainhill 1 and 2 are abandoned designs; like Elk Point 1,  
> they were more complicated than necessary.)

Oh boy!  Does this mean that Rainhill 3 will be simpler than Elk  
Point 2?  I love Elk Point 2 and am still considering choosing it as  
my personal favorite, but it does suffer from being more complicated  
than its two competitors [2].

> If an attacker can run on the same machine as the gateway server,  
> then there are currently much more serious attacks than against the  
> crypto, e.g. the variant of #870 where the attacker binds to the  
> webapi port first.

Note that timing side-channel attacks are not necessarily limited to  
running on the same machine.  Some of them might also be deployable  
over the network, although of course those ones are harder to pull  
off in practice e.g. Bernstein 2005 [3].

One of the things that I really don't like about the timing issue in  
AES is how you have to start reasoning about deployment scenarios in  
order to figure out if it is dangerous to your users.  This is the  
opposite of the dictum of the book "Practical Cryptography" [4] which  
repeatedly asserts that security must be a property of a module in  
isolation, without regard to how it will be used.

That said, I don't *think* the current use cases for Tahoe-LAFS make  
the users vulnerable to the known timing attacks on AES (especially  
given that the AES implementation that we use [5] has a defense  
against remote timing attacks).  This is because people who need to  
keep control of their own files use a gateway running on their own  
computer so they are not vulnerable to someone else accessing their  

More things that you wrote in your letter deserve a reply, but I need  
to get some sleep as I start my new job tomorrow!



[1] http://allmydata.org/trac/tahoe/wiki/NewCaps/WhatCouldGoWrong
[2] http://allmydata.org/trac/tahoe/wiki/NewMutableEncodingDesign
[3] http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
[4] http://www.schneier.com/book-practical.html
[5] http://www.cryptopp.com/

More information about the tahoe-dev mailing list