RE: strong claims about encryption safety Re: [tahoe-dev] cleversafe says: 3 Reasons Why Encryption isOverrated
Zooko Wilcox-O'Hearn wrote:
>
> [removing Cc: tahoe-dev as this subthread is not about Tahoe-LAFS.
> Of course, the subscribers to tahoe-dev would probably be interested
> in this subthread, but that just goes to show that they ought to
> subscribe to cryptogra...@metzdowd.com.]
>
> On Monday,2009-08-10, at 11:56 , Jason Resch wrote:
>
> >> I don't think there is any basis to the claims that Cleversafe
> >> makes that their erasure-coding ("Information Dispersal")-based
> >> system is fundamentally safer, e.g. these claims from [3]: "a
> >> malicious party cannot recreate data from a slice, or two, or
> >> three, no matter what the advances in processing power." ...
> >> "Maybe encryption alone is 'good enough' in some cases now - but
> >> Dispersal is 'good always' and represents the future."
> >
> > It is fundamentally safer in that even if the transformation key
> > were brute forced, the attacker only gains data from the slice,
> > which in general will have 1/threshold the data.
>
You failed to quote the other reason I offered:
It is not dependent on asymmetric cryptography, which depends on:
1. No one ever figuring out a fast way to factor primes, an area in which there
has been substantial progress.
2. No one ever building a quantum computer with more than twice as many qubits
as your key length.
In other posts on the subject I have offered even more reasons, including:
1. It is not dependent on Password Based Encryption, which struggles to walk
the tightrope of reliability vs. confidentiality, use a long password and you
are likely to forget it, use a short one and it is easy to brute force. Write
down a long password and you've made it easier for someone to find.
2. In our system there are no master keys. Therefore a compromise of the
client computer which reads data only leads to loss of confidentiality for the
data that was read during the compromise, not the loss of confidentiality for
all data encrypted by a master key as is the case with most systems.
3. It offers an elegant solution for reliably and confidentially storing keys.
Making copies of keys is a trade-off between confidentiality and reliability,
secret sharing schemes, such as this can achieve both simultaneously.
> Okay, so the Cleversafe method of erasure-coding ciphertext and
> storing the slices on different servers is "safer" in exactly the
> same way that encrypting and then giving an attacker only a part of
> the ciphertext is safer. That is: having less ciphertext might
> hinder cryptanalysis a little, and also even if the attacker totally
> wins and is able to decrypt the ciphertext, at least he'll only get
> part of the plaintext that way. On the other hand I might consider
> it scant comfort if I were told that "the good news is that the
> attacker was able to read only the first 1/3 of each of your
> files". :-)
See above, this is just one and perhaps the most trivial and "meaningless" of
the security advantages. The biggest advantage in my mind is the way it
addresses the problem of key management, which in my opinion is the elephant in
the room for most cryptosystems. I look forward to your response on this
subject, as practically speaking it is the most relevant issue for such
systems, not which ciphers or key lengths are used.
>
>
> But the Cleversafe method of appending the masked key to the last
> slice makes it less safe, because having the masked key might help a
> cryptanalyst quite a lot.
Assuming the hash function is a random oracle, the way the key is masked is
equivalent to One-Time-Pad encryption. There would need to be an extremely
serious flaw in the hash function (such as having output bits highly skewed
towards 1 or 0, or for earlier input to have very little impact on the hash
result) for it to compromise the security of the masked key. Recall that the
hash is calculated over random-seeming encrypted data, so even if the input was
highly or specially formed to cause trouble for a hash function, the fact that
it is encrypted before hashed eliminates this type of chosen-plaintext attack.
You can point out cryptographic primitives used in AONT and say if they aren't
secure then your system isn't secure, but one could do the same for any system.
When designing systems, one should work with the assumption that the hash
algorithms and ciphers do what they are meant to, but always plan for forward
support of new algorithms if/when a critical flaw is discovered. We have done
this, implementing support for different ciphers, key lengths and hash
functions, and I believe this is about the best anyone can do when designing a
system.
>
> In any case, the claims that are
FW: cleversafe says: 3 Reasons Why Encryption is Overrated
Zooko Wilcox-O'Hearn wrote:
>
> [dropping tahoe-dev from Cc:]
>
> On Thursday,2009-08-06, at 2:52 , Ben Laurie wrote:
>
> > Zooko Wilcox-O'Hearn wrote:
> >> I don't think there is any basis to the claims that Cleversafe
> >> makes that their erasure-coding ("Information Dispersal")-based
> >> system is fundamentally safer
> ...
> > Surely this is fundamental to threshold secret sharing - until you
> > reach the threshold, you have not reduced the cost of an attack?
>
> I'm sorry, I don't understand your sentence. Cleversafe isn't using
> threshold secret sharing -- it is using All-Or-Nothing-Transform
> (built out of AES-256) followed by Reed-Solomon erasure-coding.
I would define that combination as a threshold secret sharing scheme. Noting
of course what you said below in that it is a computationally-secure as opposed
to Shamir's information theoretically secure scheme.
> The
> resulting combination is a computationally-secure (not information-
> theoretically-secure) secret-sharing scheme. The Cleversafe
> documentation doesn't use these terms and is not precise about this,
> but it seems to claim that their scheme has security that is somehow
> better than the mere computational security that encryption typically
> offers.
>
> Oh wait, now I understand your sentence. "You" in your sentence is
> the attacker. Yes, an information-theoretically-secure secret-
> sharing scheme does have that property. Cleversafe's scheme hasn't.
>
Recalling what the original poster said:
"Surely this is fundamental to threshold secret sharing - until you
reach the threshold, you have not reduced the cost of an attack?"
Cleversafe's method does have this property, the difficulty in breaking the
random transformation key does not decrease with the number of slices an
attacker gets. Though the difficulty is not infinite, (as is the case with an
information theoretically secure scheme) it does remain fixed until a threshold
is reached.
Jason
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: [tahoe-dev] cleversafe says: 3 Reasons Why Encryption isOverrated
Zooko Wilcox-O'Hearn wrote: > > [cross-posted to tahoe-...@allmydata.org and cryptogra...@metzdowd.com] > > Folks: > > It doesn't look like I'm going to get time to write a long post about > this bundle of issues, comparing Cleversafe with Tahoe-LAFS (both use > erasure coding and encryption, and the encryption and key-management > part differs), and arguing against the ill-advised Fear, Uncertainty, > and Doubt that the Cleversafe folks have posted. So, I'm going to > try to throw out a few short pieces which hopefully each make sense. > > First, the most important issue in all of this is the one that my > programming partner Brian Warner already thoroughly addressed in [1] > (see also the reply by Jason Resch [2]). That is the issue of access > control, which is intertwined with the issues of key management. The > other issues are cryptographic details which are important to get > right, but the access control and key management issues are the ones > that directly impact every user and that make or break the security > and usefulness of the system. > > Second, the Cleversafe documents seem to indicate that the security > of their system does not rely on encryption, but it does. The data > in Cleversafe is encrypted with AES-256 before being erasure-coded > and each share stored on a different server (exactly the same as in > Tahoe-LAFS). If AES-256 is crackable, then a storage server can > learn information about the file (exactly as in Tahoe-LAFS). The > difference is that Cleversafe also stores the decryption key on the > storage servers, encoded in such a way that any K of the storage > servers must cooperate to recover it. In contrast, Tahoe-LAFS > manages the decryption key separately. You have stated how Cleversafe manages the key but not provided any details regarding how Tahoe-LAFS manages the decryption key? In your documentation it was stated that many of your users choose to store the capability (containing the key) for their root file on your data storage servers. I would think that this results in less security than Cleversafe's approach because our servers enforce authentication and access controls. > This added step of including > a secret-shared copy of the decryption key on the storage servers > does not make the data less vulnerable to weaknesses in AES-256, as > their documents claim. (If anything, it makes it more vulnerable, > but probably it has no effect and it is just as vulnerable to > weaknesses in AES-256 as Tahoe-LAFS is.) I agree. I should also note that the use of AES-256 or any cipher is a configuration parameter for our generalized transformation algorithm, which also can support stream ciphers. > > > Third, I don't understand why Cleversafe documents claim that public > key cryptosystems whose security is based on "math" are more likely > to fall to future advances in cryptanalysis. I think most > cryptographers have the opposite belief -- that encryption based on > bit-twiddling such as block ciphers or stream ciphers is much more > likely to fall to future cryptanalysis. Certainly the history of > modern cryptography seems to fit with this -- of the original crop of > public key cryptosystems founded on a math problem, some are still > regarded as secure today (RSA, DH, McEliece), but there has been a > long succession of symmetric crypto primitives based on bit twiddling > which have then turned out to be insecure. (Including, ominously > enough, AES-256, which was regarded as a gold standard until a few > months ago.) Symmetric ciphers frequently break in small pieces at a time, reducing the number of bits of protection below what would be expected for the given key length. If an asymmetric algorithm were to break (due to finding solutions to factoring or discrete logarithms) those algorithms would fail utterly, no length of a key could be considered secure. This of course has not happened yet, but it remains a possibility unless it is someday proven that there is no efficient solution. Even if math does not provide a path to breaking asymmetric ciphers, physics does by way of quantum computing. Hundreds of symmetric ciphers have been devised and as weaknesses are found in currently used symmetric ciphers it is easy to migrate to other well-vetted algorithms. Asymmetric ciphers are in short supply, and depend on discover trap door functions in math, so a break in them would offer fewer exit strategies. > > Fourth, it seems like the same access control/key management model > that Cleversafe currently offers could be achieved by encrypting the > data with a random AES key and then using secret sharing to split the > key and store on share of the key with each server. I *th
RE: cleversafe says: 3 Reasons Why Encryption is Overrated
Zooko Wilcox-O'Hearn wrote:
>
> [dropping tahoe-dev from Cc:]
>
> On Thursday,2009-08-06, at 2:52 , Ben Laurie wrote:
>
> > Zooko Wilcox-O'Hearn wrote:
> >> I don't think there is any basis to the claims that Cleversafe
> >> makes that their erasure-coding ("Information Dispersal")-based
> >> system is fundamentally safer
> ...
> > Surely this is fundamental to threshold secret sharing - until you
> > reach the threshold, you have not reduced the cost of an attack?
>
> I'm sorry, I don't understand your sentence. Cleversafe isn't using
> threshold secret sharing -- it is using All-Or-Nothing-Transform
> (built out of AES-256) followed by Reed-Solomon erasure-coding.
I would define that combination as a threshold secret sharing scheme. Noting
of course what you said below in that it is a computationally-secure as opposed
to Shamir's information theoretically secure scheme.
> The
> resulting combination is a computationally-secure (not information-
> theoretically-secure) secret-sharing scheme. The Cleversafe
> documentation doesn't use these terms and is not precise about this,
> but it seems to claim that their scheme has security that is somehow
> better than the mere computational security that encryption typically
> offers.
>
> Oh wait, now I understand your sentence. "You" in your sentence is
> the attacker. Yes, an information-theoretically-secure secret-
> sharing scheme does have that property. Cleversafe's scheme hasn't.
>
Recalling what the original poster said:
"Surely this is fundamental to threshold secret sharing - until you
reach the threshold, you have not reduced the cost of an attack?"
Cleversafe's method does have this property, the difficulty in breaking the
random transformation key does not decrease with the number of slices an
attacker gets. Though the difficulty is not infinite, (as is the case with an
information theoretically secure scheme) it does remain fixed until a threshold
is reached.
Jason
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: [tahoe-dev] cleversafe says: 3 Reasons Why Encryption isOverrated
james hughes wrote:
>
> On Aug 6, 2009, at 1:52 AM, Ben Laurie wrote:
>
> > Zooko Wilcox-O'Hearn wrote:
> >> I don't think there is any basis to the claims that Cleversafe makes
> >> that their erasure-coding ("Information Dispersal")-based system is
> >> fundamentally safer, e.g. these claims from [3]: "a malicious party
> >> cannot recreate data from a slice, or two, or three, no matter what
> >> the
> >> advances in processing power." ... "Maybe encryption alone is 'good
> >> enough' in some cases now - but Dispersal is 'good always' and
> >> represents the future."
> >
> > Surely this is fundamental to threshold secret sharing - until you
> > reach
> > the threshold, you have not reduced the cost of an attack?
>
> Until you reach the threshold, you do not have the information to
> attack. It becomes information theoretic secure.
With a secret sharing scheme such as Shamir's you have information theoretic
security. With the All-or-Nothing Transform and dispersal the distinction is
there is only computational security. The practical difference is that though
2^-256 is very close to 0, it is not 0, so the possibility remains that with
sufficient computational power useful data could be obtained with less than a
threshold number of slices. The difficulty of this is as hard as breaking the
symmetric cipher used in the transformation.
>
>
> They are correct, if you lose a "slice, or two, or three" that's fine,
> but once you have the threshold number, then you have it all. This
> means that you must still defend the site from attackers, protect your
> media from loss, ensure your admins are trusted. As such, you have
> accomplished nothing to make the management of the data easier.
Is there any data storage system which does not require some protection against
attackers, resiliency to media failure, and trusted administrators? Even in a
systems where one encrypts the data and focuses all energy on keeping the key
safe, the encrypted copies must still be protected for availability and
reliability reasons.
The security provided by this approach is only the icing on the cake to the
other benefits of dispersal. Dispersal provides extremely high fault tolerance
and reliability without the large storage requirements of making copies. See
this paper "Erasure Coding vs. Replication: A Quantitative Comparison" by the
creators of OceanStore for a primer on some of the advantages:
http://www.cs.rice.edu/Conferences/IPTPS02/170.pdf
>
> Assume your threshold is 5. You lost 5 disks... Whose information was
> lost? Anyone? Do you know?
If a particular "vault" (Our term for a logical grouping of data on which
access controls may be applied) had data stored on on a threshold number of
compromised drives, then data in that vault would be considered compromised.
Our systems tracks which vaults have data on which machines through a global
set of configuration information we call the Registry.
> What if the 5 drives were lost over 5
> years, what then?
When drives or machines are known to be lost or compromised one may perform a
read and overwrite of the peer-slices. This makes obsolete any slices
attackers may have accumulated up until that point. This is due to the fact
that the AONT is a random transformation, and newly generated slices cannot be
used with old ones to re-create data. Therefore this protocol protects against
slow accumulation of a threshold number of slices over time.
> CleverSafe can not provide any security guarantees
> unless these questions can be answered. Without answers, CleverSafe is
> neither Clever nor Safe.
>
> Jim
>
>
Please let me know if you have any additional questions regarding our
technology.
Best Regards,
Jason Resch
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
