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
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 majord...@metzdowd.com
