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!
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.
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.
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.
Your assessment of Colin's article is unfair. He does do better than 'picking on them for saying "military-grade cryptography."' In particular, he points out ZumoDrive's encryption is not protected by a key known only to the owner of the data, and he points out that there are plenty of points where the plaintext and/or keys can leak out for a variety of legal and technical reasons.
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.
You completely missed the point. To access data from ZumoDrive (according to the article), all that you need is access to the EC2 instance that hosts the service. There's no need to break any encryption because ZumoDrive apparently uses SSL to provide link-level encryption, and then it encrypts the data that it gets onto the S3 storage. The fact that there is a cleartext copy of the data under the control of the service is the problem; anybody with access to ZumoDrive can get that cleartext data. With tarsnap, the data is encrypted on the client machine, and only the client ever sees the cleartext. That's the key difference.
We're clear on the key difference between Colin's service and Zumodrive's. So clear that my comment actually acknowledges it, and recommends that he rewrite his post to talk up his own design instead of berating other companies.
You appear to feel that "the only real differentiator between Zumodrive and Tarsnap is the integrity of the code that implements the service". I didn't see that as being an architectural critique, but a commentary on the quality of source code. Perhaps you did mean for that to be a comment on the design of the two services though?
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.
I like Colin's design better than Zumodrive's. I don't think serverside AES encryption is a big win for security at all. But that doesn't make Zumodrive "insecure". It makes Tarsnap "more secure". Not the same thing at all.
I don't think serverside AES encryption is a big win for security at all. But that doesn't make Zumodrive "insecure".
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.
Disclaimer I've neither used nor looked at the source for either Tarsnap or Zumodrive, all the following is based on the public statements I've read.
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.
Tarsnap encrypts your data before it leaves your machine using keys that no one but you hold. Zumodrive sends data to a remote server, decrypts it then re-encrypts it for storage. That right there seems like a whole world of difference to me (not that I'm really paranoid enough to care, I like Tarsnap for it's other awesome attributes).
(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.
(1) Calling their security/cryptography "military grade" should be a warning signal.
(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.
SSL/TLS is exactly the right tool for securing data in transit. That Zumodrive lacks the security feature of encrypting the data clientside before transmitting it under cover of TLS is not relevant to the argument.
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.
TLS is not so easy to implement correctly. You still have to decide (a) which version of TLS to support, (b) which ciphersuites to support, (c) which signature algorithms to support, (d) which CA(s) to trust, and (e) which certificate revocation checking scheme(s) to use, at least. People tend to choose the defaults, which mostly works. But, Colin does make a valid point that the default list of CAs in particular is probably not the best choice considering the policies of the companies making these default lists.
The defaults on TLS work just fine. It's not 1999 anymore; your code isn't going to accept SSL2. No decision about ciphersuites, signature algorithms, or CAs (note: just run your own) are going to impact your security.
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.
I disagree. The choice of ciphersuite is important. In particular, it is much better to choose DHE/ECDHE ciphersuites over the non-DHE/ECDHE ciphersuites to protect against the compromise of your server's private key.
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.
The funny thing about that comment is that I've worked in several environmens where DHE was not only not preferred, but explicitly banned. Not only that, but DHE is even more complicated than SSL as most people understand it --- if you're in favor of it, you're making an even stronger argument for TLS (DH is remarkably easy to screw up).
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.
The main thing I am trying to say is that, if you understand crypto enough to configure your TLS optimally, you can do the crypto without TLS. And, if you don't understand crypto and TLS this well, you shouldn't be trying to store the public's private data in a way that you claim to be secure. (This isn't about ZumoDrive; They may know quite a lot about these issues, and their choices might very well be optimal for the use cases they are trying to address.)
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.
This is so absolutely, completely untrue I hardly know where to start.
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.
If you choose a bad implementation of your crypto primitives (ones that don't make these kinds of checks) then you will get bad results. That's not surprising. The same thing happens when you choose a bad TLS implementation. Your argument is that you should use a well-known TLS stack because the bugs have been shaken out over the years. I agree with that. But, the same thing applies to the lower-level crypto protocol implementations. The common TLS implementations are implemented with the common crypto primitive implementations. For example, IIRC the checks of D-H parameters in OpenSSL are in the D-H code, not in the TLS code. So, you don't need to use the TLS part of OpenSSL to get the benefits of its carefully-written D-H implementation.
I'm not saying that anybody should go out and implement all the primitives (D-H, ECC, AES, GCM) themselves.
What's the recommendation you would make to a generalist developer on a library they can safely use to implement their own secure transport with ephemeral keying?
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.
The specific bug you mentioned really was the result of writing/choosing a bad D-H library. But, I agree with your your point that, even if you have a security expert on board, you are likely to make mistakes.
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!
I forgot to respond to this in my other reply. Your post regarding RC4 was the first one that popped into my mind when I was trying to find a post regarding sub-optimal TLS settings commonly in use.
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.
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.
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.
I wasn't sure whether to put that at the top -- one the one hand it would solve the problem you describe, but on the other hand, most of the readers of my blog already know about Tarsnap and it rather interferes with the "flow" of my text.
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 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.
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 ...).
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.
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.
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.
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.
It would be cool if you would expand more on your preference for RSA and AES-CTR-HMAC instead of ECC and AES-GCM. Since ECC and AES-GCM are in NSA Suite B, I expect that eventually they will replace RSA and AES-*-HMAC, so why shouldn't applications start using ECC and AES-GCM now?
RSA vs. ECC: This basically comes down to "ECC is complicated and you're going to screw it up".
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 ECC are (a) it is much more efficient than RSA so you can use stronger keys at less cost, (b) ECDHE is so much faster than DHE (over the integers mod Z) that ECDHE becomes practical in situations where DHE wasn't, (c) it is in NSA Suite B, (d) the major crypto libraries already implement it.
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.
There are some circumstances (e.g., mobile phones) where the efficiency of ECC is useful. But in the vast majority of applications, RSA is not going to be your bottleneck and nobody is going to be attacking the cryptographic primitive itself.
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.
Well, mobile phones are a huge market for this stuff right now. I've found that regular DHE adds latency perceivable by the end user in my mobile apps, because they have to wait for the (fast but heavily-loaded) server to calculate the modular exponentiation, and then they have to wait for their slow phone's processor to calculate the modular exponentiation.
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.
Yes, I assumed you meant AES-CBC-HMAC-SHA. But CBC mode is horrible, and nobody should use SHA any more.
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.
Wish I could make that too, but Ottawa is a little out of my travel budget this year. Also, I'm only going to get to goto one or two conferences this year and I'm not that interested in BSDCan since I don't use free BSD beyond my wireless router. I enjoy reading your writings, so I'm looking forward to your video/slides. =)
If you can make it in person and record the talk, I hope you put it on line. BTW, an intelink search didn't return anything for "postabon" except a soft drink firm.
Nice! I like your post Colin and will try to attend the conf and shoot the video for those who can't make it, if the conf doesn't make the video for you (hope there isn't copyright infringement though)
The problem is that TLS is not the right way to encrypt stored data. It's a transport mechanism. It comes with extra baggage by default, such as all the cert parsing stuff and built-in root CAs. That's the root of Colin's "what about China?" complaint.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
Either use a key on a USB device or enter a (long!) password. There are much more clever solutions (two-factor authentication involving sending an SMS to the mobile phone of the account holder, "delegate" keys that are valid for a limited amount of time, etc), but even the basic stuff works reasonably well.
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.
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.
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!