4 ms·

You completely missed the point. To access data from ZumoDrive (according to the article), all that you need is access to the EC2 instance that hosts the servi

by tsuraan 17y ago

You completely missed the point. To access data from ZumoDrive (according to the article), all that you need is access to the EC2 instance that hosts the service. There's no need to break any encryption because ZumoDrive apparently uses SSL to provide link-level encryption, and then it encrypts the data that it gets onto the S3 storage. The fact that there is a cleartext copy of the data under the control of the service is the problem; anybody with access to ZumoDrive can get that cleartext data. With tarsnap, the data is encrypted on the client machine, and only the client ever sees the cleartext. That's the key difference.

tptacek 17y ago
We're clear on the key difference between Colin's service and Zumodrive's. So clear that my comment actually acknowledges it, and recommends that he rewrite his post to talk up his own design instead of berating other companies.
- tsuraan 17y ago
  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 to encrypt people's data, and things not to say when you've failed to protect people's data. He's written other articles on how cool tarsnap is.
  - tptacek 17y ago
    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.
    - cperciva 17y ago
      I don't think serverside AES encryption is a big win for security at all. But that doesn't make Zumodrive "insecure". 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.

by tsuraan 17y ago

tptacek 17y ago

We're clear on the key difference between Colin's service and Zumodrive's. So clear that my comment actually acknowledges it, and recommends that he rewrite his post to talk up his own design instead of berating other companies.

tsuraan 17y ago
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 to encrypt people's data, and things not to say when you've failed to protect people's data. He's written other articles on how cool tarsnap is.
- tptacek 17y ago
  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.
  - cperciva 17y ago
    I don't think serverside AES encryption is a big win for security at all. But that doesn't make Zumodrive "insecure". 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.