[144635] in cryptography@c2.net mail archive
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
daemon@ATHENA.MIT.EDU (james hughes)
Sun Jul 26 07:11:56 2009
Cc: james hughes <hughejp@mac.com>, tahoe-dev@allmydata.org,
Cryptography List <cryptography@metzdowd.com>
From: james hughes <hughejp@mac.com>
To: Zooko Wilcox-O'Hearn <zooko@zooko.com>
In-reply-to: <5595A87F-5097-462F-BD8B-72B52D4DDD38@zooko.com>
Date: Sun, 26 Jul 2009 12:11:02 +0800
On Jul 24, 2009, at 9:33 PM, Zooko Wilcox-O'Hearn wrote:
> [cross-posted to tahoe-dev@allmydata.org and =20
> cryptography@metzdowd.com]
>
> Disclosure: Cleversafe is to some degree a competitor of my Tahoe-=20
> LAFS project.
...
> I am tempted to ignore this idea that they are pushing about =20
> encryption being overrated, because they are wrong and it is =20
> embarassing.
....and probably patent pending regardless of there being significant =20=
amounts of prior art for their work. One reference is =93POTSHARDS: =20
Secure Long-Term Storage Without Encryption=94 by Storer, Greenan, and =20=
Miller at http://www.ssrc.ucsc.edu/Papers/storer-usenix07.pdf. Maybe =20
they did include this in their application. I certainly do not know. =20
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 =20
> spread this kind of misinformation need to be publicly contradicted, =20=
> lest they confuse others.
...
The trick is cute, but I argue largely irrelevant. Follows is a =20
response to this web page that can probably be broadened to be a =20
criticism of any system that claims security and also claims that key =20=
management of some sort is not a necessary evil.
> http://dev.cleversafe.org/weblog/?p=3D111 # Response Part 2: =20
> 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 =20
encrypted data, the cost of your secret sharing scheme is a small =20
additional cost to bear, agreed. Using the hash to =93prove=94 you have =20=
all the pieces is cute and does turn Reed Solomon into an AONT. I will =20=
argue that if you were to do a Blakley key split of a random key, and =20=
append each portion to each portion of the encrypted file you would =20
get similar performance results. I will give you that your scheme is =20
simpler to describe.
2) In my opinion, key management is more about process than =20
cryptography. The whole premise of Shamir and Blakley is that each =20
share is independently managed. In your case, they are not. All of the =20=
pieces are managed by the same people, possibly in the same data =20
center, etc. Because of this, some could argue that the encryption has =20=
little value, not because it is bad crypto, but because the shares are =20=
not independently controlled. I agree that if someone steals one =20
piece, they have nothing. They will argue, that if someone can steal =20
one piece, it is feasible to steal the rest.
3) Unless broken drives are degaussed, if they are discarded, they can =20=
be considered lost. Because of this, there will be drive loss all the =20=
time (3% per year according to several papers). As long as all N =20
pieces are not on the same media, you can actually lose the media, no =20=
problem. This can be expanded to a loss of a server, raid controllers, =20=
NAS box, etc. without problem as long as there is only N-1 pieces, no =20=
problem. What if you lose N chunks (drives, systems, etc.) over time, =20=
are you sure you have not lost control of someone=92s data? Have you =20
tracked what was on each and every lost drive? What is your process =20
when you do a technology refresh and retire a complete configuration? =20=
If media destruction is still necessary, will resulting operational =20
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 =20=
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 =20
kind of storage system. I suggest the paper =93POTSHARDS: Secure Long-=20=
Term Storage Without Encryption=94 by Storer, Greenan, and Miller at =
http://www.ssrc.ucsc.edu/Papers/storer-usenix07.pdf=20
because it covers the same space, and has a good set of references =20
to other systems.
My final comment is that you raised the bar, yes. I will argue that =20
you did not make the case that key management is not needed. Secrets =20
are still needed to get past the residual problems described in these =20=
comments. Keys are small secrets that can be secured at lower cost =20
that securing the entire bulk of the data. Your system requires the =20
bulk of the data to to be protected, and thus in the long run, does =20
not offer operational efficiency that simple bulk encryption with a =20
traditional key management provides.
Jim
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
