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

31–40 of 74 posts

Re: ZumoDrive rolls a hard six

#31

Post by janzer »

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…

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

Re: ZumoDrive rolls a hard six

#32

Post by ableal »

tsally wrote: post #17

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

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.

Re: ZumoDrive rolls a hard six

#33

Post by briansmith »

JoachimSchipper wrote: post #13
shrughes wrote: post #3

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

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.

Re: ZumoDrive rolls a hard six

#34

Post by tsuraan »

tptacek wrote: post #27
tsuraan wrote: post #23

Earlier quoted context omitted.

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.

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.

Re: ZumoDrive rolls a hard six

#35

Post by tptacek »

janzer wrote: post #31
tptacek wrote: post #26

Earlier quoted context omitted.

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…

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

Re: ZumoDrive rolls a hard six

#36

Post by three14 »

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…

Agreed -- and this is an easier read than your top comment :)

Re: ZumoDrive rolls a hard six

#37

Post by tptacek »

briansmith wrote: post #30
tptacek wrote: post #26

Earlier quoted context omitted.

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…

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.

Re: ZumoDrive rolls a hard six

#38

Post by tptacek »

tsuraan wrote: post #34
tptacek wrote: post #27

Earlier quoted context omitted.

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…

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.

Re: ZumoDrive rolls a hard six

#39

Post by almost »

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…

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

Re: ZumoDrive rolls a hard six

#40

Post by briansmith »

tptacek wrote: post #37
briansmith wrote: post #30

Earlier quoted context omitted.

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…

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.

Post reply on HN