7 ms·
Cloud Storage Security Challenge
- jnoller 16y agoAnd the blog post with more discussion: http://www.nasuni.com/news/nasuni-blog/cloud-storage-challenge-security/ http://www.nasuni.com/news/nasuni-blog/cloud-storage-challen...
- ComputerGuru 16y agoWhat a brilliant/bullsh!t marketing campaign. Obviously if OpenPGP could be broken, there are much bigger rewards than a lame $5000 dollars from nasuni. They picked an encryption scheme that has stood the test of time and hackers. It's "known" to be secure (as meaningless as that word is in the field of security) and the only question is whether or not the NSA has some secret way of getting past it, but the general consensus is that no one does. They let others do all the hard work for them and are doing nothing more than directly using PGP/OpenGPG............. except, of course, to their average client, that has no meaning. To them, "Nasuni has done something super great with security and they're so confident, they're DARING hackers to break it." Brilliant idea, I say.
- powrtoch 16y agoKind of funny really. Once you trust the encryption scheme, the only hope of breaking it would be some unbelievably terrible screw up in the application layer. So if no one claims the prize, they've proven nothing, but if someone does, they've proven themselves worthlessly incompetent. Not that I think that will happen, just saying.
- JoeAltmaier 16y agoJust a garden-variety screwup is required. Don't have to be worthless, just normally competent and vulnerable.
- jnoller 16y agoThank you - we're happy you recognized that the encryption scheme has withstood the test of time and external scrutiny. Nasuni strongly believes in reaching out and thanking all of the people and software tools/packages which help us accomplish our goals and serve our customers. If no one wins the prize money (as we fully expect no one will) the money is being sent straight to the Free Software Foundation.
- tptacek 16y agoTaking systems like this that purport to be secure because of strong encryption and tearing them down is literally my day job. In no set of circumstances would we accept a project for which the terms are "here's an encrypted file, DECRYPT IT!". You could encrypt the file with FEAL-4 and still blow $5,000 of attacker budget "analyzing" a "system" like this. Meanwhile, there is no trivial way I can find to get details on how your system works, or on the details of what aspects of OpenPGP you use or how your system is configured to use it. To download a white paper on your security, I was asked to fill out a form. No. As a practitioner, this contest doesn't demonstrate to me the resilience of "modern encryption". It demonstrates to me that you've never had a professional assessment of your system and that you don't understand how "modern crypto" actually breaks. To someone with a basic understanding of how cryptosystems work, your contest has the impact opposite to the one you intend. Having said all that, the fact that you use OpenPGP instead of a vanity "AES plus RSA" scheme might be a plus. You know, if you documented it anywhere.
- tptacek 16y agoUgh. I like schemes that use OpenPGP, but cracking contests are Schneier's "Warning Sign #9" of Snake-Oil Security.
- jnoller 16y agoPer the blog post and challenge text: "We are issuing this challenge because we are confident that no one will succeed. In fact, we know no one will succeed – security experts will realize that this “challenge” is really more of a demonstration. This is a stunt to bring attention to the strength in modern encryption and our use of it. In reality, encryption is the least likely place to fail in a secure system. The smart attacker will know to avoid the crypto and to look for weaknesses elsewhere (frequently in people and IT processes)." We fully acknowledge and concur with Schneier.
- tptacek 16y agoAs an attacker of middling intelligence, crypto is the place I look first in custom designs for failures, because lay developers are absolutely awful at deploying it. Your stunt harms end-user understanding of how security works.
- rdl 16y agoAs an attacker of (...) intelligence, key management is the place I look first in security protocols for failures, because both lay developers and crypto engineers tend to make more mistakes there than anywhere else in crypto protocols.
- tptacek 16y agoMore than half of the crypto schemes I've looked at in the last 2 years have used ECB mode. Of the very few systems that used CTR mode, two of them had colliding nonces. Less than half of the systems I see have explicit MACs. Some of the most popular systems in the world have had padding oracles (see the recent drama around JSF, and note SSH fell to this too). Three SRP systems I've had to evaluate have had the (thanks, Nate and Trevor) zero-mod-n problem. Nate and Coda Hale have found multiple famous systems, with HMAC MACs, that are trivially timeable. No. Key management isn't the problem. Key management is what people bring up when they mean "I haven't really looked at the underlying crypto very carefully". It's a punt answer that leaves people feeling warm and fuzzy about actual cryptography, when actual cryptography is likely as not to be the thing that actually kills you.
- tednaleid 16y agoThe 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.
- balakk 16y agoOk, help me with this please. The key to the problem, literally, is the recipient key. If I understand the challenge details correctly, and the OpenPGP RFC, a recipient key is required on the cloud side to decrypt the session key. How is this recipient key stored securely on the cloud?
- jnoller 16y agoThe answer is simple: The key is never stored in the cloud. Period. The key is in your control - we don't trust the cloud for storing keys. In fact we do not trust ourselves (we do not keep a copy, unless you choose to give it to us). The only person who has access to the decryption key is you.
- motters 16y agoEncryption in the cloud is probably the way to go, but if I were running a business, and even just as a private individual, I'd still be concerned about exposure to risk either of data loss or compromise. As I'm sure everyone reading this is already aware, security is about more than just encryption algorithms. Ultimately it's a judgement call as to how secure and reliable you consider your local network to be in relation to the prospect of handing your data over to someone you don't know to store in an unknown location under unknown conditions with unknown levels of access by unknown individuals. Also, even if off-site storage is totally secure there is always the risk of your data being held to ransom at some point in the future. The cloud hosting company can arbitrarily decide to increase their administration fees at any time, and if most of your data is entrusted to them then you may have little option but to pay up (the "stand and deliver" business model).