0

Ok. So I recently signed up for Crashplan which uses 448-bit Blowfish to encrypt the data you send them, and the more I do research on Blowfish the more it sounds like the 64-bit block size is totally insufficient for the size of the volumes they will be backing up.

I've read that especially in certain modes (like CTR) it is totally insufficient for large streams of data, and can be distinguished from random data after only gigabytes? However, other stuff I've read seems to indicate this isn't an issue if properly implemented.

Would such an attack not apply to Crashplan's implementation?

Also, assuming the implementation is as perfect as it gets, is it even mildly "Post Quantum" secure?

The Founder of the company that owns Crashplan responded to a similar question here: https://superuser.com/questions/587661/crashplan-truecrypt-overkill

However, I really would like a better response from him regarding their implementation and why I should trust it for the large amount of data I'm sending to Crashplan if Blowfish's own creator says he is amazed anyone still uses it and says you should definitely use Twofish instead.

Anyone else is welcome to chime in too. I want as much info on this as possible. I'm already concerned enough that I might discontinue using Crashplan entirely.

Community
  • 1
  • 1

1 Answers1

6

A distinguisher is a pretty weak attack. It doesn't allow an attacker to decrypt the data, it only allows them to figure out that is is encrypted data, not random data.

The impact of 64 bit blocks depends a lot on the chosen mode.

  • With single-use keys in CTR mode the problems are minor. There is a distinguisher if several GB are encrypted with the same key.
  • With multiple-use keys in CTR the problems are highly problematic. Reuse of IVs is fatal with CTR.
  • With CBC they're somewhere in between.

I would not trust Crashplan's encryption, because:

  • Using Blowfish shows bad taste in crypto. It not broken, but you'll find few cryptographers who'd use it in a new product.

  • They don't document how they encrypt. One can't evaluate crypto just knowing the primitive used. Some essential questions for which I couldn't find answers:

    • Which mode is used?
    • How are keys managed? Are they single use? Multiple use?
    • How are IVs generated?
    • How is the key derived from the password?
    • How is data authenticated? With a MAC? Which one?
  • They seem to be using custom encryption instead of SSL for transport security. Good encryption for transport security is quite different from file encryption. So their claim "it is transferred securely. Not necessarily SSL but with the same encryption technology used to encrypt data during backup" is a bit worrying.
CodesInChaos
  • 106,488
  • 23
  • 218
  • 262