On Jul 24, 2009, at 9:33 PM, Zooko Wilcox-O'Hearn wrote:

[cross-posted to tahoe-...@allmydata.org and cryptogra...@metzdowd.com]

Disclosure: Cleversafe is to some degree a competitor of my Tahoe- LAFS project.
I am tempted to ignore this idea that they are pushing about encryption being overrated, because they are wrong and it is embarassing.

....and probably patent pending regardless of there being significant amounts of prior art for their work. One reference is “POTSHARDS: Secure Long-Term Storage Without Encryption” by Storer, Greenan, and Miller at http://www.ssrc.ucsc.edu/Papers/storer-usenix07.pdf. Maybe they did include this in their application. I certainly do not know. They seem to have one patent
and 7 pending.

But I've decided not to ignore it, because people who publicly spread this kind of misinformation need to be publicly contradicted, lest they confuse others.

The trick is cute, but I argue largely irrelevant. Follows is a response to this web page that can probably be broadened to be a criticism of any system that claims security and also claims that key management of some sort is not a necessary evil.

http://dev.cleversafe.org/weblog/?p=111 # Response Part 2: Complexities of Key Management

I agree with many of your points. I would like to make a few of my own.
1) If you are already paying the large penalty to Reed Solomon the encrypted data, the cost of your secret sharing scheme is a small additional cost to bear, agreed. Using the hash to “prove” you have all the pieces is cute and does turn Reed Solomon into an AONT. I will argue that if you were to do a Blakley key split of a random key, and append each portion to each portion of the encrypted file you would get similar performance results. I will give you that your scheme is simpler to describe.

2) In my opinion, key management is more about process than cryptography. The whole premise of Shamir and Blakley is that each share is independently managed. In your case, they are not. All of the pieces are managed by the same people, possibly in the same data center, etc. Because of this, some could argue that the encryption has little value, not because it is bad crypto, but because the shares are not independently controlled. I agree that if someone steals one piece, they have nothing. They will argue, that if someone can steal one piece, it is feasible to steal the rest.

3) Unless broken drives are degaussed, if they are discarded, they can be considered lost. Because of this, there will be drive loss all the time (3% per year according to several papers). As long as all N pieces are not on the same media, you can actually lose the media, no problem. This can be expanded to a loss of a server, raid controllers, NAS box, etc. without problem as long as there is only N-1 pieces, no problem. What if you lose N chunks (drives, systems, etc.) over time, are you sure you have not lost control of someone’s data? Have you tracked what was on each and every lost drive? What is your process when you do a technology refresh and retire a complete configuration? If media destruction is still necessary, will resulting operational process really any easier or safer than if the data were just split?

4) What do you do if you believe your system has been compromised by a hacker? Could they have read N pieces? Could they have erased the logs?

5) I also suggest that there is other prior art out there for this kind of storage system. I suggest the paper “POTSHARDS: Secure Long- Term Storage Without Encryption” by Storer, Greenan, and Miller at http://www.ssrc.ucsc.edu/Papers/storer-usenix07.pdf because it covers the same space, and has a good set of references to other systems.

My final comment is that you raised the bar, yes. I will argue that you did not make the case that key management is not needed. Secrets are still needed to get past the residual problems described in these comments. Keys are small secrets that can be secured at lower cost that securing the entire bulk of the data. Your system requires the bulk of the data to to be protected, and thus in the long run, does not offer operational efficiency that simple bulk encryption with a traditional key management provides.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to