[tahoe-dev] cleversafe says: 3 Reasons Why Encryption isOverrated

[Jason Resch]

Zooko Wilcox-O'Hearn wrote:
>
> [cross-posted to tahoe-dev at allmydata.org and cryptography at 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 *think* that 
> this would have the same cryptographic properties as the current 
> Cleversafe approach of using an All-Or-Nothing-Transform followed by 
> erasure coding.  Both would qualify as "computation secret sharing" 
> schemes as opposed to "information-theoretic secret sharing" 
> schemes.  I would be curious if there are any significant differences 
> between these two constructions.

We evaluated that approach shorlty before discovering the AONT and I believe it has similar security properties.  The AONT was much simpler to integrate, however, as it is a single pre-processing step before the IDA.

>
>
> 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.  Also, it avoids the threats to asymmetric cryptography that I mentioned above.

>
>
> Fifth, as I've already mentioned, the emphasis on cryptography being 
> defeated due to advances in processing power e.g. reference to 
> Moore's Law is confused.  Advances in processing power would not be 
> sufficient to crack modern cryptosystems and in many cases would not 
> be necessary either.

Many modern cryptosystems use 1024-bit RSA keys, (my bank's website for example).  The security of a 1024-bit RSA key is about equivalent to an 80-bit symmetric key.  Assuming a conservative estimate for Moore's law of doubling processing power every 2 years, a bot-net owner with 1,000,000 computers could reach that point in 28 years.  Existing trends show doubling ever 18 months, which reduces this time to about 20 years.

>
>
> Okay I think that's it.  I hope these notes are not so terse as to be 
> confusing or inflammatory.
>

I think your points were clearly written and professional.

Best Regards,

Jason Resch