[144713] in cryptography@c2.net mail archive
RE: [tahoe-dev] cleversafe says: 3 Reasons Why Encryption isOverrated
daemon@ATHENA.MIT.EDU (Jason Resch)
Tue Aug 11 10:39:05 2009
Date: Mon, 10 Aug 2009 12:56:54 -0500
In-Reply-To: <76B21C74-4822-4C00-9DB8-8EB45210FBEC@zooko.com>
From: "Jason Resch" <jresch@cleversafe.com>
To: <tahoe-dev@allmydata.org>,
"Cryptography List" <cryptography@metzdowd.com>
Zooko Wilcox-O'Hearn wrote:
>
> [cross-posted to tahoe-dev@allmydata.org and =
cryptography@metzdowd.com]
>
> Folks:
>
> It doesn't look like I'm going to get time to write a long post about=20
> this bundle of issues, comparing Cleversafe with Tahoe-LAFS (both use=20
> erasure coding and encryption, and the encryption and key-management=20
> part differs), and arguing against the ill-advised Fear, Uncertainty,=20
> and Doubt that the Cleversafe folks have posted. So, I'm going to=20
> 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=20
> programming partner Brian Warner already thoroughly addressed in [1]=20
> (see also the reply by Jason Resch [2]). That is the issue of access=20
> control, which is intertwined with the issues of key management. The=20
> other issues are cryptographic details which are important to get=20
> right, but the access control and key management issues are the ones=20
> that directly impact every user and that make or break the security=20
> and usefulness of the system.
>
> Second, the Cleversafe documents seem to indicate that the security=20
> of their system does not rely on encryption, but it does. The data=20
> in Cleversafe is encrypted with AES-256 before being erasure-coded=20
> and each share stored on a different server (exactly the same as in=20
> Tahoe-LAFS). If AES-256 is crackable, then a storage server can=20
> learn information about the file (exactly as in Tahoe-LAFS). The=20
> difference is that Cleversafe also stores the decryption key on the=20
> storage servers, encoded in such a way that any K of the storage=20
> servers must cooperate to recover it. In contrast, Tahoe-LAFS=20
> manages the decryption key separately.=20
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=20
> a secret-shared copy of the decryption key on the storage servers=20
> does not make the data less vulnerable to weaknesses in AES-256, as=20
> their documents claim. (If anything, it makes it more vulnerable,=20
> but probably it has no effect and it is just as vulnerable to=20
> 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=20
> key cryptosystems whose security is based on "math" are more likely=20
> to fall to future advances in cryptanalysis. I think most=20
> cryptographers have the opposite belief -- that encryption based on=20
> bit-twiddling such as block ciphers or stream ciphers is much more=20
> likely to fall to future cryptanalysis. Certainly the history of=20
> modern cryptography seems to fit with this -- of the original crop of=20
> public key cryptosystems founded on a math problem, some are still=20
> regarded as secure today (RSA, DH, McEliece), but there has been a=20
> long succession of symmetric crypto primitives based on bit twiddling=20
> which have then turned out to be insecure. (Including, ominously=20
> enough, AES-256, which was regarded as a gold standard until a few=20
> 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=20
> that Cleversafe currently offers could be achieved by encrypting the=20
> data with a random AES key and then using secret sharing to split the=20
> key and store on share of the key with each server. I *think* that=20
> this would have the same cryptographic properties as the current=20
> Cleversafe approach of using an All-Or-Nothing-Transform followed by=20
> erasure coding. Both would qualify as "computation secret sharing"=20
> schemes as opposed to "information-theoretic secret sharing"=20
> schemes. I would be curious if there are any significant differences=20
> 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=20
> that their erasure-coding ("Information Dispersal")-based system is=20
> fundamentally safer, e.g. these claims from [3]: "a malicious party=20
> cannot recreate data from a slice, or two, or three, no matter what=20
> the advances in processing power." ... "Maybe encryption alone is=20
> 'good enough' in some cases now - but Dispersal is 'good always' and=20
> 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=20
> defeated due to advances in processing power e.g. reference to=20
> Moore's Law is confused. Advances in processing power would not be=20
> sufficient to crack modern cryptosystems and in many cases would not=20
> 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=20
> confusing or inflammatory.
>
I think your points were clearly written and professional.
Best Regards,
Jason Resch
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
