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

backupencryptionSecurity

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.

Best Answer

  • 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.