Do I need to create my own key to have secure cloud backup with CrashPlan?

Question

I am interested in backing up my personal computer and my web server with CrashPlan.

As I understand it, CrashPlan supports 3 levels of data security:

1. Encrypt files locally, using a key provided by CrashPlan. CrashPlan has the key in (essentially) plaintext. So they can clearly see your files.
2. Encrypt files locally, using an "archive key" - a key generated locally from a password. CrashPlan servers only ever see the archive key in hashed and salted form, so presumably they can't look at your files.
3. Encrypt files locally using a custom key. The user defines the key and it never leaves the local machine.

It seems like the difference between option 2 and 3 is that, which option 3, there is the onus of me needing to keep a copy of this keyfile, which is cumbersome (vs. a password). My question is this: how much more secure is option 3?

If I have a 448 bit hashed and salted key and I have the encrypted files, how hard is it to attack and key and decrypt the files?

How much easier does this task become if the attacker knows what some of the unencrypted files look like? (For example, if I upload my whole disk to CrashPlan and it includes some standard Windows system files that every attacker would presumably know both the pre and post image of).

The cipher they are using is Blowfish.

Also, does CrashPlan encrypt only the body of the files, or does it obscure the filenames also? I'm looking to avoid the cloud-based robo-suing copyright enforcement bots of the future.

Answer 1

448 bits is quite a lot of entropy. In order to match the security of the key, the passphrase must provide a similar level of entropy. If there is any significant difference in entropy between the two, an attacker will just go for attacking whatever has less entropy.

I don't recall the exact figure, and it probably varies with language, but natural language has between 1 and 2 bits of entropy per character.

So to get to a similar level of security as a truly random 448 bit key, you'd need a passphrase of, on the order of, 300 characters. It also must not be known to anyone else, or have been used by anyone else, so famous quotes, quotes from your favorite books, and so on, are pretty much out of the question. That'd likely be the first thing someone would throw their cracker at trying to use.

For comparison, to get the required level of entropy, you need a passphrase of approximately the length of the preceding paragraph. And you must be able to type it 100% correctly, every time, quite possibly without seeing what you are typing.

With a truly random password made up from an 85-character set (say, the Base85 set), you're looking at about log2(85) ~ 6.4 bits per character. So to get to 448 bits you'd need about 70 truly random characters from an 85-character set.

Disregarding the question of whether the entropy pool has that much true entropy to begin with, you need to be able to remember the password, and keep it secure. I would dare you to remember even a single 70-character truly random password consisting of virtually every printable character in the ASCII set.

There's also the question of what attack vector someone will choose. Nobody is going to attack a 448-bit key through brute force trial and error decryption attempts; doing so is simply out of the reach of humanity at this time, and quite possibly forever, due to simple physics. Any attack on such cryptography is going to be through other methods, whether side-channel attacks, rubberhose cryptography (as exemplified by XKCD), outright theft (don't laugh!), cipher attacks more efficient than brute force, or something else. It's a lot easier to hire a few thugs to break into your home and steal your laptop, than to attack properly implemented even 128-bit symmetric cryptography.

Which leads us to:

It seems like the difference between option 2 and 3 is that, which option 3, there is the onus of me needing to keep a copy of this keyfile, which is cumbersome (vs. a password). My question is this: how much more secure is option 3?

In practice, with both options (secure password encrypting the file locally, and secure keyfile encrypting the file locally), you are going to have to safeguard a copy of the key material. So from the "how cumbersome is it?" point of view, they are roughly similar. From the security point of view, it comes down to the amount of entropy in the secret material (keyfile or passphrase).

So:

• If you are worried about someone gaining access to your files on Dropbox, then use a locally stored key file and encrypt the files before uploading. It will be more convenient for you, but if an adversary is able to gain access to your computer, they will of course have the key file. You may be able to partly work around this by combining a key file with a simpler password or passphrase.

• If you are worried about theft of your computer, then use a strong passphrase which does not exist and has never existed on your computer outside of that specific use. It will present greater difficulty for an attacker, since they will need to convince you to reveal the passphrase. Note that doing so need not be difficult; a few hints about what happens to people protecting terrorists, or a hint to a few well-placed media connections that a person matching your description is being investigated for child abuse, or something like that, might be enough.

• If you are worried about both, then use both, assuming that the software allows you to do that.

Answer 2

To answer the question, in my opinion Option 3 (custom key) is most secure provided the custom key consists of truly random characters. CrashPlan also rates this as the most secure option (see table after following link to CrashPlan information below).

However, it seems to me that three important differences between options 2 and 3 are being ignored:

Difference 1 - changing the archive key or custom key Option 2 allows one to change the archive key without invalidating earlier backups. The reason this works is because the archive key is not used to encrypt the files; the archive key is the key to the vault in which the key used to encrypt the files is stored. With Option 3, if you would ever want to change the custom key, this would invalidate all earlier backups. You would lose access to those backups and would need to start over.

Difference 2 - multiple computers on the same CrashPlan account Option 2 requires that the same archive key is used on all computers participating in the same CrashPlan backup account. Option 3 allows for each computer participating in the same CrashPlan backup account to have its own custom key.

Difference 3 - storage of the key When using Option 2 with a CrashPlan for Home account, the (secured) archive key is stored at the destination to allow guest access. With Option 3, the custom key is never stored anywhere (except where you yourself decide to store it).

Source: see http://support.code42.com/CrashPlan/Latest/Configuring/Archive_Encryption_Key_Security

Answer 3

An encrypted file is only as secure as is the password.

You would need quite a long and random password to get the same security as a 448-bit key, so presumably you would also need to keep a copy of it somewhere. So it seems to me that both options 2 & 3 are more or less equivalent.

With secure sites being hacked all over the Web, I wouldn't trust option 1, because CrashPlan is a much more attractive target for hackers than your computer, as long as you are careful with your security.

Which is probably why I would recommend option 3, although it also depends on the CrashPlan software not being hacked.

One can never have total security with CrashPlan or with any other such product. Once your computer or their software is pwned, then you have no security left. One can only set up multiple barriers that might not be worth for a hacker the effort of cracking.

For example, by encrypting your files before re-encryption by CrashPlan, or if the total volume is not too large by keeping them in a TrueCrypt volume and archiving that volume (which will need not one but two passwords). This will avoid the case of an attacker identifying a file that it knows and making it easier to deduce the key.