Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZumoDrive rolls a hard six

daemonology.net

Post reply on HN
Print view View original

21–30 of 74 posts

Re: ZumoDrive rolls a hard six

#21

Post by rythie »

pvg wrote: post #11
cperciva wrote: post #2

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.

Agreed. I feel the author conned me while reading it, when all the while it was a pitch for his own product.

Re: ZumoDrive rolls a hard six

#22

Post by wizard_2 »

cperciva wrote: post #7
smanek wrote: post #6

Earlier quoted context omitted.

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 coder…

You should come to my conference talk, "everything you need to know about crypto in 1 hour". :-) Boy, I wish something like that existed It does! I'm giving that talk at BSDCan'10 in May: http://news.ycombinator.com/item?id=1179569

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. =)

Re: ZumoDrive rolls a hard six

#23

Post by tsuraan »

tptacek wrote: post #19

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: i…

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.

Re: ZumoDrive rolls a hard six

#24

Post by three14 »

tptacek wrote: post #19

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: i…

This isn't quite fair to the original post. He makes at least two points you ignore:

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.

Re: ZumoDrive rolls a hard six

#26

Post by tptacek »

three14 wrote: post #24
tptacek wrote: post #19

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: i…

This isn't quite fair to the original post. He makes at least two points you ignore: 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.

I have three issues with this post.

(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.

Re: ZumoDrive rolls a hard six

#27

Post by tptacek »

tsuraan wrote: post #23
tptacek wrote: post #19

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: i…

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 serv…

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.

Re: ZumoDrive rolls a hard six

#28

Post by janzer »

tptacek wrote: post #19

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: i…

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.

Re: ZumoDrive rolls a hard six

#29

Post by briansmith »

tptacek wrote: post #19

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: i…

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.

Re: ZumoDrive rolls a hard six

#30

Post by briansmith »

tptacek wrote: post #26
three14 wrote: post #24

Earlier quoted context omitted.

This isn't quite fair to the original post. He makes at least two points you ignore: 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.

I have three issues with this post. (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 t…

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.

See http://chargen.matasano.com/chargen/2009/8/27/a-working-theo... for another example of a common misconfiguration of TLS implementations.

Post reply on HN