4 ms·

What's wrong with using client-authenticated SSL with predistributed keys (and only trusting the pre-distributed keys)? I trust a well-tested TLS implementatio

by smanek 17y ago

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

cperciva 17y ago
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.
- smanek 17y ago
  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.
  - cperciva 17y ago
    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 http://news.ycombinator.com/item?id=1179569
    - smanek 17y ago
      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
      - cperciva 17y ago
        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.
        iamwil 17y ago
        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.
      - khafra 17y ago
        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.
    - wizard_2 17y ago
      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. =)
    - briansmith 17y ago
- tptacek 17y ago
  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.
  - cperciva 17y ago
    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.
    - tptacek 17y ago
      I concede this point until May.
NateLawson 17y ago
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.
- cperciva 17y ago
  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. 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.

by smanek 17y ago

cperciva 17y ago

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.

smanek 17y ago
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.
- cperciva 17y ago
  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 http://news.ycombinator.com/item?id=1179569
  - smanek 17y ago
    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
    - cperciva 17y ago
      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.
      - iamwil 17y ago
        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.
    - khafra 17y ago
      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.
  - wizard_2 17y ago
    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. =)
  - briansmith 17y ago
tptacek 17y ago
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.
- cperciva 17y ago
  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.
  - tptacek 17y ago
    I concede this point until May.

NateLawson 17y ago

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.

cperciva 17y ago
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. 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.