Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
I suppose that depends on how paranoid you are. Do you care whether Crashplan can decrypt your data? If so, use Truecrypt. – Aaron Miller Apr 25 '13 at 16:01
If Crashplan can decrypt without my password and/or key, then its not real encryption, is it? – Mrchief Apr 25 '13 at 16:02
@AaronMiller - Crashplan by default encrypts all data you upload. This encryption is based on your user password. You can also encrypted files you upload by using a password you never transmit to Crashplan thus making decrypting the file by Crashplan not possible. – Ramhound Apr 25 '13 at 16:07
See where they state "there is absolutely no way to help you recover an archive password we are never privy to." and "if you lose or forget your encryption key, your backup data cannot be recovered and CrashPlan Support cannot assist with recovery." – James Apr 25 '13 at 16:32
I think what they are saying is that the encryption is basically done by a private key (similar to when you generate one for SSH) and that if you use the key they provide (unique to your account) then they keep a copy of the key and can reverse the encryption as long as you can remember the password. If you use a key that you created and lose it then they can't help you... – James Apr 25 '13 at 17:10
up vote 12 down vote accepted

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.

share|improve this answer
Your answer makes it sound like you're from Crashplan. Is it so? – Mrchief Apr 30 '13 at 14:48
If you're a CrashPlan employee, please disclose your affiliation as required by the faq. – afrazier May 4 '13 at 1:39
Come on guys. Why ask? Google him. Matthew Dornquast is Mr. CrashPlan himself. The FOUNDER of Code 42, who are the creators of CrashPlan and various other products. Vested interest? Well his answers are only ever about CrashPlan and he might be a little biased (for some unknown reason!) but don't tell me you don't think it's cool the CREATORS of products are on this site as well. He probably knows that product better than anyone else!… – Austin ''Danger'' Powers May 4 '13 at 2:20
Ah! The humble Mr. Crashplan!! Massive hat tip from the developer within me. I'm finally taking your advice! – Mrchief Jun 8 '13 at 3:50
Sorry man, 'Trust us' is never the right answer when encryption is involved. – Michael Kohne Feb 10 '15 at 1:14

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.

share|improve this answer
Adding a 'dot' won't change the whole file. Few blocks at best and Crashplan would upload those blocks only. First time backup will be slow, but afterwards, its going to be negligible impact (unless you dump giga or tera bytes of data every day.) – Mrchief May 4 '13 at 19:38

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.

       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)

share|improve this answer
Interesting indeed! Do you know what the normal read/write performance numbers are? Using eCryptFS on my Synology NAS reduced the performance by as much as 50%. – Mrchief Oct 28 '14 at 19:41
I'm not sure although you could expect performance to be similar. It would also depend on what encryption algorithm you're using and the keysize. I went with the standard option with mine. Also its worth noting that if you want plaintext filenames and deduplication capabilities, then you could do this by tweaking some options when you first create the encrypted volume. – jonmatifa Oct 29 '14 at 20:30
Similar to un-encrypted or reduced speed? If you have any numbers, it'd greatly help. – Mrchief Oct 30 '14 at 2:40

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 :-)

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .