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