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

[Zooko Wilcox-O'Hearn]

[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.

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".  :-)

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.

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.

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].

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].  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! :-))

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.  :-)

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