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

[james hughes]

This was also posted to cryptography at metzdowd.com

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

> [cross-posted to tahoe-dev at allmydata.org and  
> cryptography at 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
	http://tinyurl.com/njq8yo
and 7 pending.
	http://tinyurl.com/ntpsj9

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

Jim


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com