Your only real argument for dispersed data, as opposed to dispersed
keys, is that some unspecified magic is going to render AES insecure.
Given a) the diminishingly low probability of that happening, b) the
additional data transmission costs of dispersing the data, and c) your
requirement that a storage site be secure, high bandwidth, and
acceptable storage costs, I don't think your scheme is going to appear
attractive to many.
> Which arguments against AES are you referring to? I have stated that
> AES will offer strong security well into the future, what I believe to
> be at risk are asymmetric ciphers which rest on unproven mathematical
> assumptions and are both vulnerable to quantum computers. Therefore
> even if we used a 15360-bit RSA key, one breakthrough in math could
> render RSA useless overnight.
>
>
Unlikely symmetric cyphers used to encrypt persistent data, public key
cyphers are used for secure key distribution. If someone invented an
algorithm or device that could quickly factor very large numbers, public
key systems could be changed in a blink of the eye. RSA is hardly the
only public key cryptosystem. There are other and more would emerge is
RSA were demonstrated vulnerable.
So the issue isn't whether a cryptosystem can be attacked, but the
consequences of a success attack. Terabytes of data redundantly at many
potentially insecure sites would be at risk if AES were compromised, but
the compromise of a key (or partial key) distribute cypher would be of
almost no consequence.
The data availability for your scheme can also be significantly reduced
by the number of copies to the quorum to reconstruct a full key -- no
point in maintain encrypted data with no hope for key retrieval. This
reduces the amount of storage even more.
I'm not going to quibble with your dispersed key. Every organization
has its own institution level of paranoia. Bus if you trust AES to
encrypt each slide, they you shoud trust AES to encrypt the whole data set.
>> If someone invented an
>> algorithm or device that could quickly factor very large numbers, public
>> key systems could be changed in a blink of the eye. RSA is hardly the
>> only public key cryptosystem. There are other and more would emerge is
>> RSA were demonstrated vulnerable.
>>
>
> These are the following asymmetric encryption systems I am aware of:
>
> RSA
> Rabin
> ElGamal
> Elliptic Curve
> GGH (Lattice Encryption)
>
> The first two both depend on the hardness of factoring integers, the
> next two both depend on the hardness of the discrete logarithm problem
> and the first 4 are all vulnerable to quantum computers. GGH I know
> little about but there are published papers claiming it is insecure
> and leaks information about the plain text. There are very few well
> supported asymmetric algorithms and if a device like a quantum
> computer of sufficient size were built we would not have any good,
> well analyized alternatives.
>
Any why would you expect more? RSA is generally accepted as adequate.
There is neither financial return nor academic glory to be had by
developing another. If RSA were comprised, however, the world would
beat a path to a better solution.
If you are willing to postulate that RSA could be weakened by an
unanticipated break through in mathematics, isn't it reasonable that it
would be met by a much less spectacular advance in encryption engineering?
>
>> So the issue isn't whether a cryptosystem can be attacked, but the
>> consequences of a success attack. Terabytes of data redundantly at many
>> potentially insecure sites would be at risk if AES were compromised, but
>> the compromise of a key (or partial key) distribute cypher would be of
>> almost no consequence.
>>
>
> If one did choose to use an existing key management system to encrypt
> data stored reliably in many copies at different sites, the storage
> system as a whole (key management system + copies) can never be more
> reliable than the key management system. If the building housing the
> key management system flooded or burned down all those copies you made
> at other sites would be useless. To avoid this problem you can either
> make multiple copies of the key (insecure) or use a threshold based
> secret sharing system to distribute shares to different locations. If
> you go this far though, why not simply store the data itself using a
> secret sharing scheme? This is what dispersal offers, an ability to
> store your data in the s ame way the most secure systems store keys.
>
>
Not at all. You've convinced us all that dispersed storage is a balance
between security and availability. I'm just arguing that your system is
sufficiently robust that using it for keys obviates the need to use it
for data.
I found this article interesting - specifically it talks about a few key things for IT implementors to think about with the new standards for HIPAA - specifically - the date for compliance has been moved in a year to 2012 - although technically they are suppose to have until 2013.
What would be interesting is if anyone on this group can provide insight on what the impact of these new standards are on their cloud implementation plan for Healthcare.
There are some specifics around increasing field length, etc and having a "single registry".
Thoughts?
Very interesting thread! Keep fighting them back Jason - security
publicly scrutinized (and defended) is of a greater value than one
taken at its face value. You are doing good job so far! Well done.
I have to say I want to know more about it now - will have to go and
research all the blogs and papers, but this summer is really busy for
me :/
Anyway, from what I have seen here, I agree with Jason on many points
including security and reliability.
I also think that it's worth mentioning in the whole argument, that
the law af accellerated-returns applies also to storage, addmittedly
with not as great acceleration as it does in processing power. Both in
turns however drive the amount of data produced and data in the need
of storing.
Now, it is obvious that scaling of the systems can be maintained only,
if the systems scale at slower rates than the size of the problems
they face. In other words the fact that Jason's system scales
sub-linearly (rate depends on the required reliability, again good
selling point, as it can be adjusted) is a great selling point to me.
In 5 years time, mobile phones will have PB storage attached.
And here I would just like to ask some questions(forgive if soundiing ignorant):
Jason, with your solution, would it be possible to have some nodes in
the scheme constantly re-encrypting the slices they store, without
compromising too much of the whole system responsiveness? If so, why
not have few nodes per whole scheme churning in the background,
constantly re-encrypting the data stored, or in the intervals that
could be adjusted.
Would such solution increase the security of the whole system?
Also would it be true that the shorter the interval, the more secure data?
I know that I could possibly find answers to those doing some
homework, but since you are following this thread and you have
implemented this, it will be a piece of cake for you.
Thanks a lot!
--
Daniel Drozdzewski
Jason, critique the following:
0. Presume Jason's scheme is everything he claims it is.
1. Take a dataset and encypt it with a random key
2. Disperse the key at n sites as per #0
3. Store the encrypted datasets anywhere convenient, including
Time's Square
This has the same level of security as Jason's scheme, reduced storage,
great availability, lower bandwidth, and better locality than's Jan
dispersed data scheme.
If you believe in 256 bit AES, key management is the issue. If you
don't believe in AES, dispersed storage doesn't work.