ZumoDrive rolls a hard six
daemonology.net
daemonology.net
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!
The article wasn't just an ad for tarsnap, it was a reasonably good article on how not to encrypt people's data, and things not to say when you've failed to protect people's data. He's written other articles on how cool tarsnap is.
Yes it does. The word "insecure" needs interpretation, of course: insecure against which attackers? The only sensible answer is "insecure against the attackers they are attempting to defend against" -- and for that purpose, encrypting data on EC2 prior to storing it on S3 is completely insecure.
If ZumoDrive had said "we don't encrypt data on the server, because we trust Amazon", we wouldn't be having this discussion; it's the fact that they identified (through their actions) people-with-access-to-data-on-S3 as an adversary they want to defend against which qualifies this as insecure.
The data is unencrypted some of the time on their servers.
You shouldn't use ZumoDrive if you're a Chinese dissident because it's presumptively insecure against your risks.
(1) It jumps on a company for talking about security in reasonable language that is meaningful to lay customers. Talking about security in rigorous technical terms in your marketing material is a terrible idea. When you yell at one startup for calling SSL and AES "military grade", you're making an untenable argument against most startup marketing.
(2) It makes the inane assertion that SSL/TLS is inferior to hand-rolled cryptography (paraphrased, "because when you own the client and the server you can pre-distribute keys and avoid all of SSL's complexity"). Hold two thoughts together in your head: first, that when Colin implements something like this, he's apt to be correct; and second, that when anybody else does it, they're apt to go catastrophically awry. If Zumodrive had done anything but TLS, they'd have me yelling at them, not Colin. And based on generalist developer crypto, I'm betting my yelling would be a lot scarier.
(3) It's sniping at a competitor about security. Talking up your own security is good. Talking down someone else's security is dangerous. It's bad marketing (it's turned me --- at least for the day --- from an advocate to a detractor) and it's bad business.
There's a lot of content in Colin's post I didn't feel the need to address. Am I wrong about any of those 3 points though? If not, I'm happy with my comment.
See http://chargen.matasano.com/chargen/2009/8/27/a-working-theo... for another example of a common misconfiguration of TLS implementations.
I'm not sure what my RC4 post has to do with this discussion. RC4 vulnerabilities are what you wind up with when you don't use TLS.
The choice of CAs to trust is about excluding CAs that you won't ever use, to prevent somebody from using one of those CAs to create a certificate to impersonate your server. If you are running your own CA then you are basically doing the same thing that Tarsnap does with its hard-coded RSA keys, except that Tarsnap will trust only its hard-coded RSA keys instead of a set of dozens of other RSA keys that a default TLS configuration will accept.
Either way, the question of whether you're using ephemeral keys or not is not relevant to this discussion. Nobody is going to choose backup software based on whether the encrypted transport has forward secrecy.
It would be very interesting to read why people would ban DHE. I know DHE key exchange is tricky in TLS because TLS doesn't allow proper negotiation of the parameters like it does with ECDHE and there are no commonly agreed-upon (named) DHE parameters like there are for ECDHE and IPSEC. Luckily, things are pretty straightforward if you use the Suite B profile of TLS (RFC5430), AFAICT.
There's a big difference between whether people would choose backup software based on the algorithms being used, and what algorithms should be implemented. Many people would choose backup software without any encryption if it was easy to use and cheap.
Knowing the difference between a an ephemeral keying scheme and a basic RSA key exchange does not make you prepared to implement either.
The Tor developers thought they knew enough to implement DH. Roger Dingledine has publications going back before 2000 and did his doctorate under Rivest. But they forgot to check DH parameters for 0-mod-p (a mistake lots of people manage to make) and so fielded an anonymity network that provided very little anonymity for several years.
Cryptography isn't rocket science. It's more like pyrotechnics. There aren't that many things to remember (though there are more of them than most people think; look how the browsers screwed up RSA a few years ago). It's just that the things you need to remember aren't obvious, and when you get them wrong, you blow your f'ing hands off.
I'm not saying that anybody should go out and implement all the primitives (D-H, ECC, AES, GCM) themselves.
You sound very clueful but I don't think you've thought this through. Off the top of my head I can think of zero popular cryptosystems that haven't been burned by terrible implementation flaws. I just told you that Tor, which was implemented by someone who got a PhD under Rivest, managed to screw up DH. Your response is, "if you picked better libraries, you'd do better than Roger Dingledine". No, you wouldn't.
If Tor would have used an off-then-shelf D-H implementation that already performed that check, it wouldn't have had the vulnerability. It is definitely easier to pick a TLS implementation that is unlikely to have such flaws (now)--just pick what lots of others have been using for a long time. You could do the same with crypto primitive implementations, but you run into problems because the interfaces for different libraries are all different, and in particular the preconditions and postconditions of various operations might be different. So, user of a crypto library has to fully understand all the details in order to verify what is his responsibility and what is the library's responsibility. It would be great if there was a specification that specified what every D-H implementation must do, and what the user of a D-H implementation must do to be safe.
Actually, a similar problem exists with TLS. Right now there is a draft TLS spec. that attempts to standardize how TLS implementations check a server's certificate against the server's domain name. Since there's no standard way of doing it, its harder to verify that a given TLS implementation is actually doing it the right way. And, actually, this is something that OpenSSL and other TLS implementations punt on and force the application to deal with manually. As I'm sure you've seen, lots of applications actually don't even check at all!
In particular, your post says we shouldn't be using RC4. But, RC4 is enabled by default in most/all TLS stacks, so if you want to follow that advice, you need to change the defaults in the TLS stack.
(2) SSL/TLS isn't inferior, it's the wrong tool for the job. Using the wrong tool in encryption almost always means opening up unnecessary attacks.
(3) When the competitor has such obvious holes and not only do they have them but are trumpeting them as their strong security; I think it makes a lot of sense to point out how bad it is.
In a client/server protocol, there are all sorts of things besides your data that you need secured: metadata, command & control, identification. You need an encrypted transport. TLS is the right answer for that problem regardless of what you're doing with the underlying data.
A major point of all this is that you don't have to break TLS/SSL to get the unencrypted data from Zumodrive. They have the unencrypted data pass through their server. They almost certainly also have the final encryption key sitting on that server for all the data stored. This is a completely unnecessary hole in the security. There are other probable problems (such as given their obvious lack of understanding the basics I wouldn't be the least surprised to find that they've messed up the way they are using AES to encrypt the data) but really just this is more than enough to know to stay away.
Tarsnap on the other hand does correctly encrypt the data and have the keys held by the client and this can be verified because the complete client side source code is available.
Colin does describe some technical aspects of TarSnap: at http://www.tarsnap.com/security.html and http://www.tarsnap.com/crypto.html. In addition, he's written some very good articles about practical issues regarding crypto on his blog. (If I was going to criticize him for anything about his blog, it would be the poor UI for navigating the archives.)
Also, is this really a case of one company simply "bashing" a competitor? I don't think so. From reading his blog, Colin seems to be very passionate about crypto and security. This blog post is the same kind of reaction that many of us who are passionate about security and privacy would have. See Schneier's numerous "doghouse" posts for example. Also, see Colin's blog post where he explained what was wrong with AWS signing V1; AWS was a partner, not a competitor.
Colin's criticism of SSL/TLS should be expanded upon so we can see exactly why he thinks it is only good for key management. However, he is correct that "client encrypts, client sends to server, server decrypts, then server encrypt again with its own key" is not a great design.
Also, Colin doesn't mention anything about OpenSSL in his post.
(Non-)disclaimer: I've never met Colin or anybody involved in this discussion, and I have no business dealings with anybody involved.
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.
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.
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.
Colin provided a tasteful opposing argument to ZumoDrive's marketing, IMO.
But judging by the comments here, it sounds like I came to the wrong conclusion -- I'll edit that post to state my conflict at the top.
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 ...).
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.
It's not fun - but I have done it before. I would still contend that setting up a CA and distributing a keyring is easier and less likely to be insecure than trying to write actual secure crypto code (at least for most normal coders like myself - people like djb or cperciva are excluded ;-)).
You should come to my conference talk, "everything you need to know about crypto in 1 hour". :-)
Boy, I wish something like that existed. Every time I'm starting to feel like I know something, I learn about a new type of attack (a side-channel that leaks more than I thought possible, a length-extension that apparently violates the oversimplified hash properties I knew, etc) that makes me feel like an idiot.
You should come to my conference talk, "everything
you need to know about crypto in 1 hour". :-)
It does! I'm giving that talk at BSDCan'10 in May: http://news.ycombinator.com/item?id=1179569
I don't know if I can make it in person, but I sure hope they tape it and put it online :-D
AES-CTR-HMAC vs. AES-GCM: While GCM is better than some of the other combined authenticated-encryption algorithms, it's (a) rather complex (128-bit finite field math is messy), (b) exposes you slightly to a side channel attack on your block cipher, and (c) is no faster than AES-CTR-HMAC, so why bother?
The arguments for AES-GCM: (a) AES-GCM and AES-CCM are the only standardized CTR modes in TLS, (b) you can implement AES-GCM efficiently in constant time (see http://www.cryptojedi.org/papers/aesbs-20090616.pdf), (c) it is the NSA suite B cipher mode, (d) the alternate mode for AES in TLS (AES-CBC-SHA) requires a new initialization vector for every TLS record, which means that you need to get 128 bits of from your PRNG for every 16KB of data transfered, whereas AES-GCM mode only requires 128 bits total per connection. A strong argument against GCM mode is that OpenSSL, NSS, and the Windows CryptoAPI (prior to Windows 7/2008R2) do not implement it yet.
Do you have a link to something that shows that AES-CTR-HMAC-SHA-256 is really faster than AES-GCM? That is something I've always wondered about.
Since you'll be at a BSD conference, I bet you won't get too many people questioning your suggestion to use OpenSSL. But, in the Linux world it seems there's a big push by Red Hat, SuSe, and other enterprise Linux vendors to replace OpenSSL with NSS in every application they support, because of NSS's huge advantages over OpenSSL w.r.t. FIPS-140 validation.
The only difference between AES-GCM and AES-CTR-HMAC-SHA256 is the MAC -- for encryption, AES-GCM just uses AES-CTR. So the question comes down to which MAC is better -- HMAC-SHA256 or evaluate-a-polynomial-over-a-finite-field-then-AES-encrypt. The latter is possible to do in constant time, but takes some work; the former is almost impossible to do not in constant time. As for performance, I haven't done any tests, but just given the bit-complexity of finite field multiplication, I'm sure HMAC-SHA256 is much faster.
For the record, I would never recommend AES-CBC-SHA. That's an absolutely horrible construction which nobody should ever use.
When I said AES-CBC-SHA, I meant AES-CBC-HMAC-SHA. The TLS ciphersuites are named without explicitly saying "HMAC"; e.g. TLS_RSA_WITH_AES_128_CBC_SHA is RSA key exchange with AES-128 in CBC mode as the bulk cipher, authenticated with HMAC-SHA1.
The practical problem that people will have with your advice is that they will want to implement it using TLS (despite your recommendation not to use SSL), and TLS doesn't have any standard AES-CTR-[HMAC-]SHA256 cipher suites; there's only standards for AES-CBC-[HMAC-]SHA, AES-GCM, and AES-CCM.
And I agree that out of AES-CBC-SHA, AES-GCM, and AES-CCM, the best choice is AES-GCM. But my advice was primarily directed towards people not using TLS.
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.
You should hear my talk before you accuse it of constituting professional malpractice.
ZumoDrive sounds like a poor design. It uses a strong transport channel with extra baggage (certs, ASN1, many cipher suites) to move data to a server, where it is in plaintext form until it is encrypted by some unknown program that uses AES in some unknown mode. When I see a design like this, I say it doesn't "hang together" well. It has a number of links in a chain, and any failure compromises your data.
Colin's points are right on. Thomas is also right, but he's picking a different argument (that roll-your-own crypto would have been worse than SSL). But both of them also missed the point that ZumoDrive apparently roll-their-own in the server side component that encrypts the data before storing it. It's AES + mumble mode + key generated who knows how + no mention of integrity protection.
Following both Colin's client-based design and Thomas's insistence on off-the-shelf crypto would have been possible and straightforward. Generate a PGP key pair for each client, encrypt/sign the data with it, then upload it to the service. The service wouldn't even need a login component -- you just register your pub key with the server when you sign up and all files signed with that key could be stored in your account. Instant strong authentication on a granular basis.
I'm not entirely happy with gnupg's security record either (it's better than OpenSSL, but not by far), but if you want to use off-the-shelf tools then I agree that this would certainly be much better.
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.
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.)
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.
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.
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.
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.
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.)