
Cloud Storage Security Challenge - jnoller
http://www.nasuni.com/news/cloud-storage-challenge-security/
======
ComputerGuru
What 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
Kind 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
Just a garden-variety screwup is required. Don't have to be worthless, just
normally competent and vulnerable.

------
tednaleid
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
Yes - 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
Unless 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.

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

------
tptacek
Ugh. I like schemes that use OpenPGP, but cracking contests are Schneier's
"Warning Sign #9" of Snake-Oil Security.

~~~
jnoller
Per 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
As 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
As 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
More 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_.

------
balakk
Ok, 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
The 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.

------
jnoller
And the blog post with more discussion: [http://www.nasuni.com/news/nasuni-
blog/cloud-storage-challen...](http://www.nasuni.com/news/nasuni-blog/cloud-
storage-challenge-security/)

