Crashplan + TrueCrypt - Overkill?

Question

Crashplan already has an option to encrypt the data. And if selected, this stores the encrypted file on the server.

Truecrypt certainly has lot more options, but for basic usage, wouldn't CrashPlan's encryption suffice?

Update: After trying CrashPlan, I'm not sure if the said encryption is anything real. Sure, it creates a container file that you cannot open and look in to, but if you go to CrashPlan's website, you can:

• see your entire folder structure
• see individual files
• restore individuals files or group of files any which way you like.

Encryption is supposed to be one-way traffic, if the data is available in plain sight, then I'm not sure if it is encryption. Maybe encoded but not encrypted. Am I missing something here?

Answer 1

Disclosure: I am the CEO and a Founding Partner of Code42

It's overkill. To make matters worse, it'll slow down your backups and delay data protection as the realtime monitoring wont work and encrypted data isn't compressible.

By using private data password (recommended) or generating your own key, you are ensured privacy. (Yes, you have to trust us on saying this, but unless you're a software/security expert personally studying/auditing the truecrypt code, you've got to trust something/someone.

If you have data so precious you can't trust anyone, doubling up encryption is reasonable. However, I'd only do that for that specific set of data - let CrashPlan handle the rest.

Answer 2

I am a TrueCrypt user, but if I was using CrashPlan I would definitely avoid encrypting my data with another product before feeding it to CrashPlan to handle then push over the internet (as the performance would most likely go from good -> painful). If you encrypt a 1GB folder, which contains numerous tiny Word documents, suddenly all you have is a 1GB homogenous blob of data that can't be efficiently handled by your backup software. So, if you add a single extra period to one of those Word docs, then re-save, your TrueCrypt archive file is now ENTIRELY different, and the WHOLE thing has to get backed up again. I would be inclined to trust CrashPlan's encryption (you've got to trust the encryption of these services or find one you DO trust). If you had a small text file with domain administrator passwords and can't sleep at night without double-encrypting it, that's fine, but you'd want to avoid any massive encrypted files (TrueCrypt or otherwise) as the impact on performance will be an increase in network bandwidth, and much slower backups- all for an increase in security you (arguably) don't need. If you are a lawyer, or have medical-related information, then you might have a legal obligation to double-encrypt, or perhaps you can get some sort of legal reassurance from Code 42 that the encryption can be trusted for that kind of data (perhaps you'd have a duty to do that in such a situation, I'm not sure- haven't personally come across this kind of data at work yet). If you were using Dropbox (a company which admits that 5% of their employees have access to the data stored by users in order to maintain and troubleshoot!) then encryption is pretty much essential for anything more than your shopping list, but I would be inclined to trust services which offer encryption as part of the package).

Or the short answer:

... yeah, it's probably overkill.

Answer 3

Short answer

Probably yes, unless you're a high-profile target.

Long answer

CrashPlan either encrypts data using password protected certificates, or no encryption at all. In this summary, you can think of a certificate as basically a frigging huge password stored in a file with your name attached to it. This certificate file is commonly encrypted, just to ensure that a quick copy of the file is not enough to access the data--you need the certificate file password too.

Most CrashPlan users likely use what is called escrow certificate storage, where Code42 stores the certificate files for you in encrypted form. When you provide your password, these certificate files are themselves decrypted, and are then used to decrypt your raw data. This is why the CrashPlan web interface can allow you to browse your data - after you provide the certificate password, their software can access the data using the certificate. The main security holes with this:

• You trust Code42+employees to store your certificate securely
• You trust Code42+employees not to ever store your certificate password insecurely
• You trust Code42+employees not to give your certificate file or password to any agency (such as a government) that requests (e.g. subpoena) it
• As I mention above, your certificate is a very big password. If anyone gets their hands on that file, the the only thing stopping them from using it is your certificate password, so if you made it hunter42 you're pretty screwed. Basically, breaking your certificate password is likely fairly easy if someone is really motivated and you didn't choose a good password.

You can also use a "custom key" (e.g. when you provide the certificate file). This means that Code42 does not store their certificate on their servers. They still store encrypted data on their servers, but if you want to see it in the web interface then you need to provide their software with both the certificate file and the certificate password. Now here's the odd part: this offers almost no realistic additional security over the above option, it's mostly useful for a system with many user accounts that you want to keep separate. You still:

• Trust the CrashPlan application not to store or transmit your certificate file or certificate password
• Trust Code42 not to make any attempt to store this data

The main benefit here is that Code42 cannot reply to an external request for your certificate as easily as they could if you use escrow certificates, they would have to willfully instruct their local CrashPlan application to retrieve your certificate key from your computer and deliver it to them. This would naturally be a huge risk for them due to the business fallout if such a decision ever became public knowledge.

One more relevant point: They apparently always store your certificate file in unencrypted form on your local computer. So if you're a high-profile target, it's feasible someone could acquire your encrypted data from CrashPlan and then execute a simple attack on your personal computer to recover the unencrypted certificate file.

So the answer to your question boils down to "do you trust Code42 with protecting your data from both internal and external threats?" If the answer is no, then encrypting your data using something like TrueCrypt as a second layer of protection is a great idea.

PS - For what it's worth, I love that CrashPlan encrypts quite heavily by default, so don't interpret this as a bashing CrashPlan post--I just want to help users understand who they are trusting :-)

Answer 4

An interesting alternative may be using EncFS, specifically with the --reverse flag. There's apparently a port to Windows, so you may be able to do the same thing there.

   --reverse
       Normally EncFS provides a plaintext view of data on demand.  Normally it stores enciphered
       data and displays plaintext data.  With --reverse it takes as source plaintext data and pro-
       duces enciphered data on-demand.  This can be useful for creating remote encrypted backups,
       where you do not wish to keep the local files unencrypted.

       For example, the following would create an encrypted view in /tmp/crypt-view.

           encfs --reverse /home/me /tmp/crypt-view

       You could then copy the /tmp/crypt-view directory in order to have a copy of the encrypted
       data.  You must also keep a copy of the file /home/me/.encfs5 which contains the filesystem
       information.  Together, the two can be used to reproduce the unencrypted data:

           ENCFS5_CONFIG=/home/me/.encfs5 encfs /tmp/crypt-view /tmp/plain-view

       Now /tmp/plain-view contains the same data as /home/me

       Note that --reverse mode only works with limited configuration options, so many settings may
       be disabled when used.

EDIT - Be sure to save your .encfs5 or encfs6.xml files, they'll be located in the original plaintext directory and not the backup directory, so you'll need to be sure to grab those as you wont be able to recover your encrypted files without them. (it would be nice if encfs included those with the encrypted files so that you could make a self contained backup archive)

Answer 5

Unless you hold information on your PC relating to a multi-million dollar patent,documents related to legal action(such as a lawsuit) or have classified information on your PC crashplan encryption should be enough.

If the stakes are high enough hackers could be hired to brute force your password.

Answer 6

The issue as I see it is speed/efficiency vs security. By encrypting with Truecrypt first the updates will likely be slow and inefficient as previously mentioned. However, post-Snowden, the other issue is that even if you create your own custom key from a complex password you have to trust that this will never be leaked. Whether by accident or because the NSA forced the American company that owns Crashplan to insert a mechanism for doing so. Encrypting on the local client is a plus point but unless you (or rather the community at large) can see the client code then there is no way of being sure your key, and hence your data, is safe.

Although it doesn't follow the strict 3-2-1 backup theory I'm going to be using an offsite encrypted HDD populated using rsnapshot and rotated regularly with other copies. I considered Crashplan over all other cloud options but the unverifiable nature of the client put me off. Were they to have an API and the EFF or other FOSS source provide the client then I'd reconsider.