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

2009-08-13 Thread 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 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 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 

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

2009-08-12 Thread 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 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.


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