[144733] in cryptography@c2.net mail archive
RE: strong claims about encryption safety Re: [tahoe-dev] cleversafe says: 3 Reasons Why Encryption isOverrated
daemon@ATHENA.MIT.EDU (Jason Resch)
Thu Aug 13 08:12:26 2009
Date: Wed, 12 Aug 2009 18:03:40 -0500
In-Reply-To: <A18DD5DD-EE8A-4852-8CEE-810634E54BC0@zooko.com>
From: "Jason Resch" <jresch@cleversafe.com>
To: "Zooko Wilcox-O'Hearn" <zooko@zooko.com>,
"Cryptography List" <cryptography@metzdowd.com>
Zooko Wilcox-O'Hearn wrote:
>
> [removing Cc: tahoe-dev as this subthread is not about Tahoe-LAFS. =20
> Of course, the subscribers to tahoe-dev would probably be interested=20
> in this subthread, but that just goes to show that they ought to=20
> subscribe to cryptography@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=20
> >> makes that their erasure-coding ("Information Dispersal")-based=20
> >> system is fundamentally safer, e.g. these claims from [3]: "a=20
> >> malicious party cannot recreate data from a slice, or two, or=20
> >> three, no matter what the advances in processing power." ...=20
> >> "Maybe encryption alone is 'good enough' in some cases now - but=20
> >> Dispersal is 'good always' and represents the future."
> >
> > It is fundamentally safer in that even if the transformation key=20
> > were brute forced, the attacker only gains data from the slice,=20
> > 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=20
> storing the slices on different servers is "safer" in exactly the=20
> same way that encrypting and then giving an attacker only a part of=20
> the ciphertext is safer. That is: having less ciphertext might=20
> hinder cryptanalysis a little, and also even if the attacker totally=20
> wins and is able to decrypt the ciphertext, at least he'll only get=20
> part of the plaintext that way. On the other hand I might consider=20
> it scant comfort if I were told that "the good news is that the=20
> attacker was able to read only the first 1/3 of each of your=20
> 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=20
> slice makes it less safe, because having the masked key might help a=20
> 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 made on the Cleversafe web site are=20
> wrong and misleading: "a malicious party cannot recreate data from a=20
> slice, or two, or three, no matter what the advances in processing=20
> power" [1]. It is easy for customers to believe this claim, because=20
> an honest party who is following the normal protocol is limited in=20
> this way and because information-theoretically-secure secret-sharing=20
> schemes have this property. I kind of suspect that the Cleversafe=20
> folks got confused at some point by the similarities between their=20
> AONT+erasure-coding scheme and a secret-sharing scheme.
I agree that statement you quoted is misleading. It should have come =
with an asterisk that to be protected against advances in processing =
power, one must use a random transformation key long enough that it =
cannot be cracked by any foreseeable technology within the life of the =
universe. Whether or not a 256-bit key meets this requirement is up to =
debate, but the AONT+Dispersal protocol is not limited to any particular =
key length. Note that this contrasts with systems dependent on =
asymmetric algorithms, for which there is a foreseeable technology that =
could break keys of any length.
AONT+Dispersal is a secret sharing scheme, just not information =
theoretic like the Shamir Scheme. Not all secret sharing schemes have =
the property of being information theoretically secure. We abandon it =
seeing more value in the storage and I/O efficiency than the practical =
benefits of information theoretic security vs. the difficulty of =
breaking a 256-bit key. It is the same reason hardly anyone uses OTP =
encryption, that level of security is too costly for its benefits.
>
>
> In any case, the statement quoted above is not true, and not only=20
> that isolated statement, but also the entire thrust of the=20
> "encryption isn't safe but Cleversafe's algorithm is safer" argument=20
> [2]. Just to pick out another of the numerous examples of misleading=20
> and unjustified claims along these lines, here is another: "Given=20
> that the level of security provided by the AONT can be set=20
> arbitrarily high (there is no limit to the length of key it uses for=20
> the transformation), information theoretic security is not necessary=20
> as one can simply use a key so long that it could not be cracked=20
> before the stars burn out." [3].
How is that misleading or unjustified? One could use a massive key so =
long that it couldn't possibly be cracked. For example a 448-bit =
Blowfish key. One quickly reaches a point where the cost/difficulty of =
stealing a threshold number of storage nodes will be << the =
cost/difficulty of cracking the transformation key, and at that point, =
what does it matter if it is information theoretic or just 2^448 in =
complexity?
>
> On the other hand Cleversafe's arguments about key management being=20
> hard and about there being a trade-off between confidentiality and=20
> availability are spot on: [3].=20
Thank you.
>
> Although I don't think that their=20
> strategy for addressing the key management issues is the best=20
> strategy, at least their description of the problem are correct. =20
> Also, if you ignore the ill-justified claims about security on that=20
> page, their explanation of the benefits of their approach is=20
> correct. (Sorry if this comes off as smug -- I'm trying to be fair.)
>
> (I'm not even going to address their third point [4] -- at least not=20
> until we take this conversation to the law mailing list! :-))
I too would prefer to avoid discussions on topics of law. As far as I =
know, however, the bill that would have eliminated the encryption safe =
harbor has not been passed and most likely was abandoned after being =
moved around a few committees. Nevertheless, on the topic of disclosure =
itself, dispersal offers some strong protection against accidental and =
ill-intentioned exposures.
>
>
> Okay, I think I've made my opinion about these issues fairly clear=20
> now, so I'll try to refrain from following-up to this subthread --=20
> the "strong claims about encryption safety" subthread -- unless there=20
> are some interesting new technical details that I haven't thought=20
> of. By the way, when googling in the attempt to learn more=20
> information about the Cleversafe algorithm, I happened to see that=20
> Cleversafe is mentioned in this paper by Bellare and Rogaway: "Robust=20
> Computational Secrete Sharing and a Unified Account of Classical=20
> Secret-Sharing Goals" [5]. I haven't read that paper yet, but given=20
> the authors I would assume it is an excellent starting point for a=20
> modern study of the cryptographic issues. :-)
Interesting reference, I will check into it.
>
>
> I still do intend to follow-up on the subthread which I call "So how=20
> do *you* do key management, then?", which I consider to be the most=20
> important issue for practical security of systems like these.
>
> Regards,
>
> Zooko, writing e-mail on his lunch break
>
> [1] http://dev.cleversafe.org/weblog/?p=3D63
> [2] http://dev.cleversafe.org/weblog/?p=3D95
> [3] http://dev.cleversafe.org/weblog/?p=3D111
> [4] http://dev.cleversafe.org/weblog/?p=3D178
> [5] http://www.cs.ucdavis.edu/~rogaway/papers/rcss.html
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to =
majordomo@metzdowd.com
I too believe it to be the most important issue, as the confidentiality, =
reliability, and availability of an encrypted storage system is =
necessarily bounded by the confidentiality, reliability and availability =
of the key storage system. I eagerly await what you have to say on this =
topic.
Jason
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
