Hacker News Reader

Comment by smanek | Hacker News Reader

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

View on HN

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.

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.

    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 thought you were being sarcastic!

I don't know if I can make it in person, but I sure hope they tape it and put it online :-D

If nothing else, I'll put my slides online -- but coming in person would give you the opportunity to hear me speak and ask questions at the talk, too.

Sweet. I'll be looking forward to the slides, or if there's a video of the talk. I feel like I don't know enough at all about security.

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.

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

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

My talk is basically an expansion of that blog post.

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.

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)

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.

Make up your own mind.

Recommending that developers implement their own cryptography after watching you talk for an hour is pretty close to professional malpractice.

You should hear my talk before you accuse it of constituting professional malpractice.

I concede this point until May.

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.

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.

Reply on news.ycombinator.com