Zero-Knowledge File Sharing for the paranoid

This is part 2 of this post. Here I focus on online File Sharing services that advertise “zero-knowledge encryption”. Sounds very secure? Maybe, but maybe not if you are as paranoid as I am. Thankfully, there’s a way out.

In this context, “zero-knowledge” means that the service administrators cannot possibly get the plaintext of your files, which reside encrypted in their servers. This is because they are missing a key that is necessary to decrypt something, which maybe decrypts something else, and so on, which eventually decrypts your files. That key is made client-wise within your computer and they never see it, even though they typically see everything else. This begs the question of whether their knowledge is truly “zero” as they claim, but let’s not get hung up on that. Paranoid as I am, if I am convinced that they’ll never have a chance to see that one key, I’ll sleep comfortably.

One of the services, DropSecure, has made some nice graphs that I’m going to rip off in order to explain things.

This one shows how you would encrypt your files with symmetric encryption. You are 1, encrypting confidential file 2 in your computer with a symmetric key. The encrypted file gets sent to the service 3, and stored at 4. The graph has the key also being sent to the service, who stores it at 5, but this is no good for the paranoid, because then the service has both the encrypted file and the key that decrypts it. It is better to send the key to the recipient 6 by a separate channel. The security of this channel is very important and a tough problem to solve. Some services have you putting the key in the URL that you are going to send to the recipient, behind a hashtag so that the recipient won’t forward that information to the server when the encrypted file is requested from them. But of course, a URL that you text or send by email is not particularly secure, either. If someone intercepts it and asks the service to decrypt the file (hopefully politely because they are being supported by your taxes), they can do it and you’ll never know.

This other picture shows the DropSecure process with asymmetric public key encryption. Now your computer makes a key pair instead of a single key, comprising a private key and its matching public key. The public key is derived from the private key through a fairly simple process, but the reverse process is deemed many orders of magnitude harder. For all practical purposes, you cannot get the private key from its public key. The public key encrypts, the private key decrypts. So now you 1 encrypt your file 2 with a one-use symmetric key 3, and also encrypt that key with the recipient’s public key, to turn it into 4. Once again, the service 5 stores both pieces of encrypted data 6 and 7, which they cannot decrypt because they don’t have the recipient’s decryption key. Now the recipient 8 requests the file, and the service sends both, not just the confidential file. The recipient first decrypts the file key using his/her private key (which no one else knows), and then the file itself can be decrypted. The whole process implies a previous exchange of public keys between sender and recipient, which does not need to be super-secure because you cannot get a private key from its public version. The service itself is managing that exchange of public keys, which is okay with paranoid me so long as they authenticate their users properly. The other services that use asymmetric encryption, such as Mega.nz and Sync.com, follow a very similar protocol.

With this method, the service never sees that precious private key that decrypts the key that encrypts the file. That key has never left the sender’s private computer. It’s even possible that this key isn’t even there outside the time when it’s being used. Not exactly “zero” knowledge, but it does the job.

Where things can get dicey is when you are sharing your previously loaded encrypted file with someone new. He/she won’t be able to decrypt the key stored at 7, which was encrypted with public key(s) belonging to other users. A service that wants to make the process seamless to its users while remaining zero-knowledge will have to send the encrypted key 7 back to the file owner 1, instruct the owner’s computer to decrypt it, then encrypt it again with the new recipient’s public key in addition to all the previous sharers’ public keys (likely all sent along with this request), and then send it to the storage place 7 again. The service itself can’t do this process because the encrypted key must be decrypted first, and supposedly they don’t have any of the private keys that can do that. Any service that does this at the server instead of at the owner’s machine is cheating. One fairly simple way to do this, which does not require knowing any of the users’ private keys, is by encrypting those file keys also with the service’s backdoor public key, which the client software knows from installation.

Typically, services’ published descriptions and white papers on their encryption methods do not give details about their process for sharing encrypted files. They may be concerned about users getting confused, because it can be quite confusing, especially if they are trying to impress users with their “military-grade” cryptography, or they may be hiding something. Even if they publish their code, you can’t be sure that it is being used. If they support a Web interface, you can look at the code that is running on your browser, which supposedly is doing all that I described above, but unfortunately all commercial services suffer from the rather awful habit of minifying their client code (perhaps to save a few measly kilobytes within megabytes of pictures, interface libraries, and other junk) so it’s pretty impossible to read and audit.

This post is getting long, so I’m going to wrap up with a table listing the leading file sharing services that advertise zero-knowledge encryption, showing what type of encryption they use, whether or not encrypted files can be shared within their service (you can always encrypt a file with your own symmetric method before uploading it, then share the key with your friends by some secure channel), whether they store any encrypted keys (which would make them not zero-knowledge, strictly speaking), whether they integrate with the operating system so you can use their encrypted folders like any other without having to open your browser and retrieve files from the Downloads folder, and finally the cost of their cheapest plan and how much storage they give you. I am adding two entries that are actually the combination of any file sharing service (not necessarily zero-knowledge at all) with a local app that handles the encryption and decryption. One of them is my recently released GroupEncrypt, open sourced here, and free to download here.

Notes:

1. The market leader in this segment, BoxCryptor, was recently acquired by Dropbox and is not taking any new customers. They closed my account. Clearly in sunset mode.
2. DropSecure offers file sharing with unsubscribed users by symmetric key, asymmetric key for subscribed users.
3. There are two modes in GroupEncrypt. Default is Folder mode.
4. Even though pCloud’s basic service is free, adding a non-shareable Crypto folder costs $4.99/mo.
5. Maybe not quite comparable, but this is their cheapest plan. DropSecure does not offer a free plan.

I have highlighted desirable features, but refrained from giving scores for those features because readers may differ on what’s important to them. Asymmetric encryption is a must if you want to share the files with others securely. Storing key files, even if encrypted, may be a no-no for the very paranoid. The ease of use that comes from OS integration may be necessary for some. Cost is important for everybody, but you need to weigh that against the other features that you want, and what capacity and bandwidth you are offered.

You may notice that GroupEncrypt checks just about every desirable feature. I could have added more, such as being open-source, having code that can be inspected as it runs, and keeping the File Sharing service from even seeing your collection of public keys, but then it might seem like a lot of self promotion (ahem!). Don’t take my word. Try all the options presented here, add some that I haven’t mentioned. Share your thoughts in the comments below.