Home Features Security Pricing Blog Download

Wuala Blog

Thursday, 21 April, 2011

Wuala's Encryption For Dummies

As a Secure Online Storage, Wuala employs an elaborate encryption scheme to ensure the privacy of your data. This blog post will describe how Wuala's encryption works in layman's terms and what happens, when files are uploaded, shared, and downloaded.

1. Master key

When you enter your username and password, the Wuala client uses a so-called key derivation algorithm (PBKDF2) to derive your master key. For example, if your name is "Ted" and your password "Det", it mixes them up in a predefined way and ends up with something like "9B78EFC0457A3001E7ECC724147712A9". Normally, it is good if things are fast. Here, it is important that this derivation is as slow as possible but not slow enough for the user to notice (maybe 10ms). This helps to guard a little against brute-force attacks because if it takes 10ms to calculate the key from a password, an attacker can try at most 100 passwords per second. Still, if you want an attack to take millions of years, you should choose a password with ten characters, better more.

2. Folder tree

Once the master key is derived, Wuala downloads your root item from our servers and decrypts it with the key. If you have entered the wrong password, this results in unreadable garbage and Wuala asks you to enter it again. If the decryption is successful, you will get a list of your root folders and their encryption key. For example, it might say there is a folder 'Documents' that is encrypted with key "71D880EE...". When you access that 'Documents', Wuala downloads that folder item and decrypts it with its key. What it finds after decryption is another list of folders and their encryption keys. It's like a Matryoshka doll. Every folder can have additional folders and files in it encrypted with their own keys. Computer scientists call this "tree", with your root item being the root and your files being the leaves of the tree.

When a new folder is created, a new file or folder is created, a new random key is generated and inserted into the tree. The content of a file is treated in a special way. Here, the chosen encryption key is not random, but derived from the content itself. That way, if the same file is inserted twice, Wuala will choose the same key in both cases and end up with the same encrypted file content. This allows to detect duplicate files so you don't have to upload them again. Also, if you insert the same file twice, you only have to pay for it once.

3. Sharing

When sharing a folder, all you need to do is give your friends the key to that folder. With that key, it is possible to decrypt all the items in that branch of your folder tree. Basically, this is also the key you see in the URL when you share a folder with a secret weblink. When someone accesses such a file with the Wuala client, all decryption happens locally. However, when a file shared by weblink is accessed with a web browser, the key is sent to our servers so it can decrypt the requested items and send them to your browser. Even though our web servers forget the key after serving the web page, it is more secure to access files using the Wuala client as there, the key never needs to leave your computer.

When sharing a folder with a friend or inviting someone to a private group, the key of that folder or group is encrypted with the public key of that user and deposited on our servers. When logging in, the other user then can decrypt that message with his private key and gains access to the folder or group. When revoking access from a folder or removing a member from a group, all keys need to be exchanged. This can be compared to exchanging all the locks of a building. For large groups, this transaction can take a while to execute.

These are the basics of Wuala's encryption. Feel free to also read our publication called Cryptree for a deeper understanding.

Post Comments

Blogger gst said...

Just a suggestion: While PBKDF2 is much better than simple hashing or bcrypt, the scrypt algorithm seems to have much better characteristics in terms of resilience against brute-force attacks. The implementation is open-source and available at http://www.tarsnap.com/scrypt.html

April 21, 2011 19:04 PM

Blogger justonequestion said...

Just one question. What happens if I change the wuala password? Have only the root item to be downloaded, decrypted with old pw, encrypted with new pw and all ist fine?

April 22, 2011 23:14 PM

Blogger anon said...

Hm...let me summarize something:
1) The file I want to upload gets hashed.
2) Now Wuala encrypts the file with its hash.
3) Wuala hashes the encrypted file again.
4) This hash (not the first one) gets sent to Wuala.
5) Wuala now checks if this file is already available on the Wuala network (all servers plus the peers).
6) If the hash is found my encrypted file won't get uploaded because it's already "in the cloud" (although it was actually uploaded by someone else).

My questions:
Does Wuala really check the WHOLE Wuala-network for the hash? Or does it only check my uploaded files to see if I have already uploaded the file?

Why I'm asking this: If you (as Wuala) have the exact same file as I have (for example some music-file) you would know who of your users also have this file (since they have the same hash, get encrypted by the hash and therefore the new hash is also the same). Or does this not work because you would need to get access to the folder first where my file is inside and you can't because the folder gets encrypted with my key (not a hash). And you could also check if Alice has the same file as Bob (since those encrypted files have the same hash).
I'm quite confused at the moment. Pls clarify.

April 23, 2011 4:21 AM

Blogger anon said...

Ok, seems like I have founf some more information about this. Read these:

April 23, 2011 5:18 AM

Blogger Luzius Meisser said...

@gst: thanks for the hint.
@justonequestion: exactly. The keys further down in the tree are replaced on their next update (so called 'lazy revokation').
@anon: That are exactly the relevant links where this is explained.

April 26, 2011 12:11 PM

Blogger Fabio D. said...

Thanks for this post that is very explicative. There is only one thing that I don't undestand (I tried to read the Cryptree pdf but is far beyond my knowledge).

If I upload a file, and then make the folder public (completely public, not shared), I presume that my client send the key to your servers, so the files in the folder can be decrypted and anyone can download it with a browser.

Later, if I make the folder private again, what happen? Forget for a while that you have the file in clear, so we must assume that the security of that file is compromised definitely. I think that the most secure thing to do would be delete the file on the server, and upload again, so it is encrypted on the client with a new key. But I noted that the process is istantaneous even for big files, so clearly the file are not uploaded again. I thought at 3 possible scenarios:

1) the client create a new key, send it to the servers and the servers re-encrypt the file. Not secure, as you know the key.

2) the server create a new key, re-encrypt the file and send the key to the client. Not secure, as you know the key.

3) the server maintain the original encrypted file, and simply delete the copy in clear. Not secure, as you know the key (my client sent it when making the file public).

So I must assume that if a file become public at a certain point, that file security is compromised forever.

My assumptions are correct or I'm wrong? can you clarify this point?

In every case, Wuala is great!

May 1, 2011 21:16 PM

Blogger Luzius Meisser said...


The answer to this question is a concept known as 'lazy revokation'. When you publish a folder, the encryption key of that folder is revealed to everyone. When you make the folder private again, the key of that folder and the keys of all its subfolders are replaced with new keys. However, we keep the keys of the files until they change (that's why it is called lazy).

Benefit: you don't need to download all the files, reencrypt and upload them again when setting the folder back to private.

Drawback: an attacker that wants to download the files even after you have made them private again needs a little less storage space to perform the attack. With reuploading, an attacker must copy all files to his own storage space if he wants to still be able to download them after you have made the folder private. With lazy revokation, an attacked only needs to store the encryption keys of all the files somewhere, which requires somewhat less storage space. Note that the latter is not supported by the Wuala client, so the only practical way for an attacker to have continued access to your files is by copying them while he has access to them. I don't think this is a problem.

May 16, 2011 16:29 PM

Blogger Markus said...

To sum this up, you could say Wuala encryptes and stores the folder keys on Wuala servers. To attack them, a hacker needed access to the key storage and needs to run a brute force attack on the encrypted keys?

How secure is the key storage @Wuala?

May 17, 2011 11:22 AM

Blogger Luzius Meisser said...

@Markus: exactly. For the security of the key storage, we rely on AES-128. Somebody who eavesdrops on your connection for example could intercept some of your encrypted items and run a brute force attack on them. Also note that there is no dedicated key store. The encrypted keys are stored together with other file and folder metadata.

May 18, 2011 10:31 AM

Blogger SGT said...

Wuala uses AES to encrypt the data. That is fine. What I would like to know however, is which mode of operation is being used? That does not seem to be covered in any of your articles.

May 18, 2011 16:13 PM

Blogger Luzius Meisser said...

@SGT: We use CBC mode. To be able to support random access to files, files are split into 100kB blocks and each block encrypted separately with its own initialization vector.

May 18, 2011 17:59 PM

Blogger SGT said...

@Luzius, How is this IV generated?

May 19, 2011 8:23 AM

Blogger Luzius Meisser said...

@SGT: from the block number. So the 17th block of a file as 17 as IV.

May 19, 2011 10:55 AM

Blogger SGT said...

@Luzius: So the IV is used in a predictable way? Isn't that a no-no for encryption in CBC mode? there are literature on the web on the risks of using IVs in a predictable manner.

May 19, 2011 11:26 AM

Blogger Luzius Meisser said...

@SGT: I guess you have the the "TLS CBC IV" attack in mind. This won't work with Wuala as the attacker cannot specify the plaintext.

I suggest to continue our discussion by email (luzius AT wuala DOT com).

May 19, 2011 11:59 AM

Blogger Anonymous said...

So if I share a file with a friend, I send a URL to that file to my friend. My friend then can download the file by clicking the URL? What happens if an attacker randomly generates URL's and tries to download whatever file?

June 22, 2011 10:35 AM

Blogger Luzius Meisser said...

@Anonymous: if the randomly generated URL is valid, the attacker can download your files. But thanks to the key at the end of the URL, it is very unlikely that an attacker could ever correctly guess an URL. I'd recommend the attacker to play Lotto instead, the chances of winning the national lottery every week for a whole year are much better than correctly guess a secure URL.

June 23, 2011 15:38 PM

Blogger Snaky Love said...

This is all very nicely explained, however, as long as he sourcecode to your client and the server components are not accessible openly, nobody can check what you are writing here.
For all the newbies: encryption software has to be open sourced in every detail to be taken seriously - if you have to trust the developers, it is not safe. it´s a principle that can not be changed. No open source = not safe. very easy.

June 25, 2011 14:35 PM

Blogger Brian said...

From reading this, the one concern I'd have is that while Wuala can't read the contents of any files I upload, they COULD easily verify I uploaded a particular file. They could do this by encrypting the test file themselves using the file key derivation function described above, and checking if the encrypted test file matches any encrypted files I have stored. And more generally, ANYONE can verify that a particular file is stored in Wuala by uploading the file themselves and seeing if deduplication is performed (they could just watch their network traffic to see if the file is uploaded).

Knowing I'm storing a file where the contents are already known isn't as big an issue as being able to read an arbitrary file I upload. But it DOES seem like there could be some unexpected privacy concerns here. Deduplication is obviously nice for everyone, but are the trade-offs worth it?

June 26, 2011 17:29 PM

Blogger Brian said...

The only comment I have is that the file encryption method would seem to allow Wuala to verify if you were storing a particular file with known contents (since files with the same contents are encrypted the same way), or for anyone to verify that some file was stored in Wuala. That seems like a privacy issue you might not expect from the way the service is described. I understand the convenience of deduplication, but it seems to me like there are some privacy concerns that go along with it.

June 26, 2011 20:13 PM

Blogger Luzius Meisser said...

@Brian: that's right. For a more detailed discussion, please have a look at feature request 3339 (http://bugs.wuala.com/view.php?id=3339) .

June 27, 2011 9:28 AM

Blogger Anonymous said...

Which perfectly explains why most banks and governments tend operate off proprietary software and not GNU/Linux, doesn't it?

December 19, 2012 2:02 AM

Post a Comment