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

41–50 of 74 posts

Re: ZumoDrive rolls a hard six

#41

Post by tptacek »

briansmith wrote: post #40
tptacek wrote: post #37

Earlier quoted context omitted.

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…

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.

Re: ZumoDrive rolls a hard six

#42

Post by briansmith »

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

Is the content going to be much different than your "Cryptographic right answers" post?: http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...

Re: ZumoDrive rolls a hard six

#43

Post by weihan »

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

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)

Re: ZumoDrive rolls a hard six

#44

Post by briansmith »

tptacek wrote: post #41
briansmith wrote: post #40

Earlier quoted context omitted.

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…

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

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.

Re: ZumoDrive rolls a hard six

#45

Post by 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.

Re: ZumoDrive rolls a hard six

#46

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

Re: ZumoDrive rolls a hard six

#47

Post by tptacek »

briansmith wrote: post #44
tptacek wrote: post #41

Earlier quoted context omitted.

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

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

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.

Re: ZumoDrive rolls a hard six

#48

Post by briansmith »

tptacek wrote: post #47
briansmith wrote: post #44

Earlier quoted context omitted.

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

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

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.

Re: ZumoDrive rolls a hard six

#49

Post by tptacek »

briansmith wrote: post #48
tptacek wrote: post #47

Earlier quoted context omitted.

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

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…

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.

Re: ZumoDrive rolls a hard six

#50

Post by evgen »

briansmith wrote: post #33
JoachimSchipper wrote: post #13

Earlier quoted context omitted.

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

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.
Post reply on HN