3 ms·
The biggest thing that invalidates this contest IMO is this disclaimer at the bottom: "When participating in this Challenge, no illegal activities are permitted
by tednaleid 16y ago
The biggest thing that invalidates this contest IMO is this disclaimer at the bottom: "When participating in this Challenge, no illegal activities are permitted or condoned and any illegal acts or practices will be grounds for automatic disqualification from the Challenge."
As if doing something illegal would stop a real world attack.
- jnoller 16y agoYes - we wish to keep the focus of the challenge on the data within the cloud. We fully understand that in reality, most attacks do not occur directly against encrypted data. The idea we are trying to get across is that the data we store, in the cloud, is secure against the number one cloud storage adoption concern - leakage of personal and corporate data.
- rdl 16y agoUnless you are doing a lot of extra (expensive) magic, I could easily do: 1) Traffic analysis of your read/write patterns -- probably not a huge issue for many web apps, but there are enterprise apps where I could probably do some harm. You would need to do some crazy blinding to protect from this, at a directly higher S3 and bandwidth cost. 2) DoS (mainly, try to compromise the Amazon S3 credentials; or, a malicious Amazon) -- all I'd need to do is flip one bit in your bucket and your OpenPGP checksums wouldn't match...; I could also do malicious MITM attacks between S3 and the "cloudlane" box) 3) Availability attacks vs. S3 -- for a lot of users, confidentiality and integrity are important, but if I can make S3 unavailable to you at the network layer, it might kill the online performance of your application. This isn't as big a deal for archival storage, but if someone thinks using crypto for confidentiality is enough to move an otherwise-in-house app to the cloud safely, it might be fun to provide some user education.