Daemonic Dispatches

Wuala update

First, the comment I quoted from Dominik's interview with Allan Stern concerning the CIA and "top secret" was a mistake, and the interview has already been corrected to replace "used by the CIA for top secret files" with "state-of-the-art encryption" (which is a fairly reasonable thing to say about AES at least). I wish reporters were so accommodating when I pointed out mistakes in their stories!

Second, Dominik provided some of the details which, while critical to the overall security of a system, weren't mentioned on the Wuala website:

• Wuala is (currently) using AES-128 in the ECB (electronic codebook) mode of operation, apparently because of its advantage in terms of seekability. This is really bad -- it allows an attacker to recognize repeated blocks of data -- and the same seekability can be obtained by using AES-128 in CTR (counter) mode. (In fact, even cipher block chaining is seekable for reads). Dominik tells me that this will be changed.
• Wuala is using SHA-256 to verify the integrity of files. This sounds good at first, but then the question arises as to how the integrity of the SHA-256 hashes will be verified. Right now it seems that the SHA-256 hashes are being stored on Wuala's servers, along with other file metadata -- which is fine if you trust Wuala, all of Wuala's employees, any data centre technicians who might have access to their servers, et cetera. Obviously I'm a bit skeptical about this, and one of my design principles in tarsnap is that it should never be possible for the server to tamper with users' files. Hopefully Wuala will start signing files directly to fix this problem.
• Apparently Wuala relies upon a key which is generating by hashing a username and password. Obviously weak passwords are a danger, but dictionary attacks can be made far more difficult by using a smarter key generation function -- specifically, one which is slow. The longer it takes to convert a password into a key, the longer it will take for a dictionary attack to work -- and while nobody is going to care if it takes 5 milliseconds instead of 5 microseconds to compute their encryption key from the password they just entered, slowing down an attacker from six CPU-years to six thousand CPU-years in his search for keys with 45 bits of entropy might just make him think twice. It sounds like Wuala will be switching to a slower key generation function soon.
• Key management in Wuala is performed using a nifty but rather complex system called Cryptree. I like the overall design of this system, but I worry that it might be pushing into the realm of "too complex to get right the first time" -- in cryptography, just like every other area of computing, more lines of code inevitably means more bugs and more potential security flaws.

Overall, I can't say that my correspondence with Dominik has made me eager to try out Wuala as it currently exists. On the positive side, as Dominik has pointed out, they're still in alpha testing, and have lots of time to get the security details right before Wuala enters widespread use. Dominik certainly seems interested in fixing the problems (which is more than I can say for certain other people) so we'll have to wait and see -- hopefully the Wuala website will be updated at some point to describe how all of these issues are being addressed, so that Wuala's security can be assessed without needing to get into an email exchange.

UPDATE 2008-11-07: Wuala's security has significantly improved.