strong claims about encryption safety Re: [tahoe-dev] cleversafe says: 3 Reasons Why Encryption isOverrated

[Jason Resch]

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 cryptography at 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 made on the Cleversafe web site are 
> wrong and misleading: "a malicious party cannot recreate data from a 
> slice, or two, or three, no matter what the advances in processing 
> power" [1].  It is easy for customers to believe this claim, because 
> an honest party who is following the normal protocol is limited in 
> this way and because information-theoretically-secure secret-sharing 
> schemes have this property.  I kind of suspect that the Cleversafe 
> folks got confused at some point by the similarities between their 
> 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 
> that isolated statement, but also the entire thrust of the 
> "encryption isn't safe but Cleversafe's algorithm is safer" argument 
> [2].  Just to pick out another of the numerous examples of misleading 
> and unjustified claims along these lines, here is another: "Given 
> that the level of security provided by the AONT can be set 
> arbitrarily high (there is no limit to the length of key it uses for 
> the transformation), information theoretic security is not necessary 
> as one can simply use a key so long that it could not be cracked 
> 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 
> hard and about there being a trade-off between confidentiality and 
> availability are spot on: [3]. 
Thank you.
>
> Although I don't think that their 
> strategy for addressing the key management issues is the best 
> strategy, at least their description of the problem are correct.  
> Also, if you ignore the ill-justified claims about security on that 
> page, their explanation of the benefits of their approach is 
> 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 
> 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 
> now, so I'll try to refrain from following-up to this subthread -- 
> the "strong claims about encryption safety" subthread -- unless there 
> are some interesting new technical details that I haven't thought 
> of.  By the way, when googling in the attempt to learn more 
> information about the Cleversafe algorithm, I happened to see that 
> Cleversafe is mentioned in this paper by Bellare and Rogaway: "Robust 
> Computational Secrete Sharing and a Unified Account of Classical 
> Secret-Sharing Goals" [5].  I haven't read that paper yet, but given 
> the authors I would assume it is an excellent starting point for a 
> 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 
> do *you* do key management, then?", which I consider to be the most 
> 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=63
> [2] http://dev.cleversafe.org/weblog/?p=95
> [3] http://dev.cleversafe.org/weblog/?p=111
> [4] http://dev.cleversafe.org/weblog/?p=178
> [5] http://www.cs.ucdavis.edu/~rogaway/papers/rcss.html
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at 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 at metzdowd.com