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