51–60 of 74 posts
Earlier quoted context omitted.
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...
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.
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.
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…
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.
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…
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.
Earlier quoted context omitted.
My reaction was, "Oh, this is cperciva's blog, that man knows his stuff."
Agreed but few things are most distasteful than technological catfighting.
Colin provided a tasteful opposing argument to ZumoDrive's marketing, IMO.
Earlier quoted context omitted.
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 .
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.
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 wi…
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…
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 p…
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.
Earlier quoted context omitted.
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 th…
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'…
You should hear my talk before you accuse it of constituting professional malpractice.
Earlier quoted context omitted.
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…
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!