
ZumoDrive rolls a hard six - cperciva
http://www.daemonology.net/blog/2010-03-11-zumodrive-rolls-a-hard-six.html
======
tptacek
If you're going to write an article overtly bashing your competitors, you
should do better than picking on them for saying "military-grade
cryptography".

The fact of the matter is that the only real differentiator between Zumodrive
and Tarsnap is the integrity of the code that implements the service. Nobody
is going to break TLS in order to get Zumodrive data.

Cryptography has exactly one implication for attackers: it is an opportunity
to cause unexpected things to happen at the target. This is only possible when
you do something unusual with cryptography. From that perspective, Tarsnap
worries me more than Zumodrive: there is nothing that is going to go wrong
with their SSL implementation that I'll be able to take advantage of, and I
can't say that about your contraption.

(Here you will inevitably point to a string of OpenSSL security advisories to
attempt to refute this point. You won't be convincing, for two reasons. First,
it's been a long time since someone found an OpenSSL flaw that would move the
dials for an attacker in a basic one-way-authenticated SSL session. Second, no
security practitioner would trust your code _more_ than OpenSSL, which, while
terrible, has had something like 15 years of audit exposure.)

From what I can see, nobody professional has stated that they've looked at
Zumodrive _or_ Tarsnap. I'm pulling for you, Colin, but you haven't earned the
right to impugn other people's security.

You should rewrite your article. Instead of trying to tear down a competitor,
you should write an article about how Tarsnap is different from other backup
solutions. You should write about how your threat model is different, and how
you believe you're the only solution that has been architected to encrypt
backup data in such a way that even the hosting providers can't access it.

You blew a bunch of credibility by trying to make these points while sniping
at a competitor. Instead of thinking about how great Tarsnap is, I'm left
questioning the objectivity of every line you wrote. What a waste! There's a
reason every business book in the universe says not to disparage competitors.
Go read one!

~~~
cperciva
_you should do better than picking on them for saying "military-grade
cryptography"_

Have you read Schneier's "snake oil" post? It's all about "how you can pre-
judge products from their advertising claims" -- Schneier's words, not mine.
You see a classic snake-oil claim, and you immediately know that they're
getting stuff wrong.

 _it's been a long time since someone found an OpenSSL flaw that would move
the dials for an attacker in a basic one-way-authenticated SSL session_

The great thing about SSL for an attacker is that there are lots of ways to
attack it. Do certificates with NUL characters move your dials? How about a
certificate which is forged by exploiting an MD5 collision?

 _There's a reason every business book in the universe says not to disparage
competitors._

I think you've already established from our past conversations that I'm a
really crappy businessman. I didn't write this post in an attempt to steal
ZumoDrive's customers -- most of them wouldn't be able to get Tarsnap
installed.

I wrote this post as a security guy, because ZumoDrive's smug "even Cylons
won't be able to access your data" attitude annoyed me. I hope you'll agree
that I know something about security and cryptography and am entitled to speak
from that perspective.

~~~
tptacek
Have you read anything I've said about Schneier? Sorry, I don't hang on his
words quite the same way you seem to be.

You're also taking Schneier out of context. Schneier was talking about
genuinely batshit products like VMA and TriStrata, products that claimed to
have redefined encryption or to use 4 meg keys. He wasn't talking about people
claiming that _AES_ was military grade.

The terrible thing about OpenSSL for an attacker is that everyone has already
attacked it. NUL characters broke it. CA's with MD5 broke it. Session
resumption broke it. As an attacker, how I wish I had something other than
OpenSSL to work with! I could break it with NUL characters! It'll rely on MD5
somewhere!

You wrote your post as a security guy. You have a conflict of interest. I
think you stepped over the line. You clearly disagree. Let's agree to
disagree.

~~~
cperciva
_He wasn't talking about people claiming that AES was military grade._

Well, no. But only because AES didn't exist yet. Saying "this is secure
because it uses 256-bit AES" is just as bogus as saying "this car will be fast
because it has a powerful engine" -- and the CNSS knows it, which is why NSA-
approved cryptography consists of "an approved algorithm; an implementation
that has been approved for the protection of classified information in a
particular environment; and a supporting key management infrastructure"... not
just the algorithm itself.

I'm having trouble understanding how someone who wrote "if you're typing the
letters A-E-S into your code, you're doing it wrong" fails to grasp the
bogosity inherent in "using AES makes this military grade". I thought you'd be
cheering me on at this point.

------
cperciva
I feel bad about bashing a YC company -- even though I'm not part of YC, I
feel that I've been on news.YC for long enough to be at least somewhat part of
the YC community -- but seriously, this is your idea of security? I'm sure you
can do better.

~~~
pvg
Don't. The only thing I'd suggest is the disclaimer "I'm just the author of a
competing service -- Tarsnap. [...]" belongs at the top. It doesn't invalidate
your points but if there's any reason to perceive a conflict of interest, the
sensible thing is to get it out of the way first, rather than as an aside at
the end.

~~~
paraschopra
Yup, honestly, the post is really good but the plug at the end gave a linkbait
flavor to the whole thing.

~~~
DougBTX
My reaction was, "Oh, this is cperciva's blog, that man knows his stuff."

~~~
constantinople
Agreed but few things are most distasteful than technological catfighting.

~~~
jhancock
I don't see this as a cat fight. People using online backup services are being
sold "security". Not all users care about, much less understand, security to
the extent that user of tarsnap do, but users should know if a product's
marketing matches the reality of the product. It is common in most industries
for a competitor to point out these gaps.

Colin provided a tasteful opposing argument to ZumoDrive's marketing, IMO.

------
smanek
What's wrong with using client-authenticated SSL with predistributed keys (and
only trusting the pre-distributed keys)?

I trust a well-tested TLS implementation more than I trust whatever crypto I
can manage to write myself.

Also, to provide the features ZumoDrive does, they have to have access to your
unencrypted data - don't they? They aren't even attempting to keep your data
safe from their server (and never claim to). It's not the trade-off I would
chose for my company's production data (my company - Postabon - uses Tarsnap
for that ;-)) - but it's perfectly valid for my low-sensitivity personal files
(I use Dropbox for most of my personal stuff).

(Incidentally, as someone with active TS clearance who has written 'military
grade' code currently deployed on JWICS, 'military grade' doesn't mean that
much in terms of crypto - at least for the 'application level' stuff I worked
on ...).

~~~
cperciva
_What's wrong with using client-authenticated SSL with predistributed keys
(and only trusting the pre-distributed keys)?_

If you set up your own CA and you distribute a CA keyring with only that CA
key, you avoid the what-about-China problem. But you still have a heck of a
lot of moving parts which can break. (EDIT: Also, I'm 99% certain that
ZumoDrive isn't doing this.)

 _I trust a well-tested TLS implementation more than I trust whatever crypto I
can manage to write myself._

You should come to my conference talk, "everything you need to know about
crypto in 1 hour". :-)

 _Also, to provide the features ZumoDrive does, they have to have access to
your unencrypted data - don't they?_

To be honest, I haven't looked at exactly what features ZumoDrive has. I just
saw them making bogus claims about their security, and decided to call them on
it.

~~~
tptacek
Recommending that developers implement their own cryptography after watching
you talk for an hour is pretty close to professional malpractice. Most
professionals --- including many who have done a lot more crypto that you ---
would recommend _the exact opposite_.

Here's an easier argument that lands in the same place: if you roll your own
crypto, and it breaks, you will look incompetant. Everybody will ask, "why
didn't you just use TLS?", and your answer will be "so I could write this
custom protocol that just destroyed my security!" On the other hand, if you
use TLS, and someone asks why, you will simply say "because if TLS fails,
people are going to target the banks and stock exchanges before they target my
service."

For the record: you have Colin Percival on HN suggesting that hand-rolled
crypto beats SSL. Colin's a smart guy who really knows crypto.

You also have Thomas Ptacek on HN suggesting that Colin is absolutely full of
it. Thomas isn't as smart as Colin, but, on the other hand, Thomas has been
breaking software professionally since 1995, and has more crypto findings than
Colin.

Make up your own mind.

~~~
cperciva
_Recommending that developers implement their own cryptography after watching
you talk for an hour is pretty close to professional malpractice._

You should hear my talk before you accuse it of constituting professional
malpractice.

~~~
tptacek
I concede this point until May.

------
shrughes
The problem I have with ZumoDrive's security claims is not that they're
insecure -- they sort of have to be, given the feature set they have -- it's
just that their claims are theatrical.

They could make things so that data can only be accessed right when the user
enters their password, without having to give up the cross-user deduplication
that I presume they'd perform, but ultimately, if you want a convenient online
storage service, with data meant to be shared across computers, and browsable
online or in other convenient circumstances, going with full-blown Tarsnap-
like security is going to be a pain.

~~~
JoachimSchipper
I admit that deduplication isn't going to work if you encrypt everything with
different keys, but why can a Tarsnap-like design not be "convenient" in the
way you seem to use the word?

A few good (encrypted!) indices are all you need. You could write something
like a WebDAV proxy if you want to make it "universally" accessible.

(Of course, Tarsnap isn't designed for this, but that doesn't mean that it
couldn't be.)

~~~
briansmith
You upload the file with computer A, and you want to download it with computer
B. Computer B has to be able to decrypt the file that was encrypted on
computer A. If you want this to be doable without keys being installed
computer B ahead of time (for example, you want to be able to go over to your
friend's house and download the file from his computer, using just the web
browser), then the server has to know the encryption key.

For my own personal use, I prefer something more like Tarsnap's or Mozy's
design, but the benefits of ZumoDrive's design definitely would be appealing
for many users.

~~~
evgen
No, computer B just needs some way to access the encrypted key for the files
from computer A. You can either have computer A create a master key that gets
encrypted with a user-supplied password and then handed out to any client that
passes a "does user A approve of this transfer" check, or you can use fine-
grained ACLs or capabilities similar to what is done in something like Tahoe-
LAFS. The server does not need to see unencrypted data in either case.

~~~
shrughes
The hard part here is for computer A to be sure it's handing the information
it thinks it's handing it to. No matter how you do it, computer A needs to be
sure it's giving permission to computer B, and not somebody claiming to be
computer B, and that involves either personally meeting beforehand to trade
some kind of keys or trusting a third party.

~~~
evgen
Thus the additional re-encryption of the master key. If this re-encryption key
is secure then you don't need to care who the master key is handed out to as
only an authorized party can decrypt it. There are other, more complicated,
crypto schemes that can make this process easier or more secure, but something
like this has KISS appeal.

An external channel is required here (to transmit the re-encryption key) but
that can be as simple as a phone call or email; anything that does not need to
pass through the third-party holding the data files.

------
tsally
Every time I see one of your websites I think of a homeless guy holding a sign
that says: "will trade strong crypto for good web design". :-p

~~~
ableal
I am reminded of these old lines by Neal Stephenson:

 _The Hole Hawg is a drill made by the Milwaukee Tool Company. If you look in
a typical hardware store you may find smaller Milwaukee drills but not the
Hole Hawg, which is too powerful and too expensive for homeowners. The Hole
Hawg does not have the pistol-like design of a cheap homeowner's drill. It is
a cube of solid metal with a handle sticking out of one face and a chuck
mounted in another. The cube contains a disconcertingly potent electric
motor.[...]_

I have no objections to beautiful design externals, but would prefer it
dresses up good engineering instead of hiding shoddy innards.

Actually, the other day a nice Mac online backup app showed up here, and my
private thought was that the author and Colin could probably profit from a
collaboration.

------
drm237
How can you possibly compare a consumer service ment to make it easy to access
files across multiple devices with a backup solution ment only for the most
technical people? Can you imaging if ZumoDrive had you (or your parents?!)
generate your own crypto keys which you would then have to manually transfer
to your iphone when you wanted to access your data on it? Think a web
interface sounds nice? Great, just login with your username, password, and
crypto keys (that hopefully you have memorized), so we can decrypt your files
and render a web interface.

The article makes some decent point and if you're storing the nuclear launch
codes, yeah, don't put them in ZumoDrive. Otherwise, the article would have
been much more useful if it suggested alternatives that would still operate
within ZumoDrive's existing user experience.

~~~
cperciva
I wasn't comparing ZumoDrive to Tarsnap (except in the very last paragraph). I
was comparing ZumoDrive to their own propaganda.

------
shabda
> So as you can see, the Cylons have many hurdles to overcome in order to take
> over ZumoDrive and your data.

Isnt that essentially wrong? The cycolns have to overcome exactly ONE hurdle
to steal the data. (Not a security guy by any strech of definition.)

~~~
cperciva
It depends in part on how you count things; but yes, ZumoDrive is more
weakness-in-width than defence-in-depth.

