Re: cleversafe says: 3 Reasons Why Encryption is Overrated

2009-08-09 Thread james hughes


On Aug 6, 2009, at 1:52 AM, Ben Laurie wrote:


Zooko Wilcox-O'Hearn wrote:

I don't think there is any basis to the claims that Cleversafe makes
that their erasure-coding (Information Dispersal)-based system is
fundamentally safer, e.g. these claims from [3]: a malicious party
cannot recreate data from a slice, or two, or three, no matter what  
the

advances in processing power. ... Maybe encryption alone is 'good
enough' in some cases now  - but Dispersal is 'good always' and
represents the future.


Surely this is fundamental to threshold secret sharing - until you  
reach

the threshold, you have not reduced the cost of an attack?


Until you reach the threshold, you do not have the information to  
attack. It becomes information theoretic secure.


They are correct, if you lose a slice, or two, or three that's fine,  
but once you have the threshold number, then you have it all. This  
means that you must still defend the site from attackers, protect your  
media from loss, ensure your admins are trusted. As such, you have  
accomplished nothing to make the management of the data easier.


Assume your threshold is 5. You lost 5 disks... Whose information was  
lost? Anyone? Do you know? What if the 5 drives were lost over 5  
years, what then? CleverSafe can not provide any security guarantees  
unless these questions can be answered. Without answers, CleverSafe is  
neither Clever nor Safe.


Jim

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


Re: Client Certificate UI for Chrome?

2009-08-09 Thread James A. Donald

Peter Gutmann wrote:
 This is predicated on the assumption that it's
 possible to make certificates usable for general
 users.  All the empirical evidence we have to date
 seems to point to this not being the case.  Wouldn't
 it be better to say What can we do to replace
 certificates with something that works?, for example
 TLS-SRP or TLS-PSK?

For password-authenticated key agreement such as TLS-SRP
or TLS-PSK to work, login has to be in the chrome.

Of course, for certificate distribution to work, we also
need password-authenticated key agreement in the chrome,
for in practice, certificates are distributed via
username and password based logins, making their use
case necessarily small.  No matter what we do with
certificates, have to fix username and password based
logins first.

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


Re: Client Certificate UI for Chrome?

2009-08-09 Thread James A. Donald

Thomas Hardjono wrote:

Having worked at a large CA for along time (trying to push for client-side 
certs with little luck), here are some thoughts on what Chrome could provide:


There are use cases where a centralized authority is useful.
Client side is not one of them.

Typical usage is is this client one of our gang?.
Obviously the CA just gets in the way.


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


Re: cleversafe says: 3 Reasons Why Encryption is Overrated

2009-08-09 Thread Zooko Wilcox-O'Hearn

[dropping tahoe-dev from Cc:]

On Thursday,2009-08-06, at 2:52 , Ben Laurie wrote:


Zooko Wilcox-O'Hearn wrote:
I don't think there is any basis to the claims that Cleversafe  
makes that their erasure-coding (Information Dispersal)-based  
system is fundamentally safer

...
Surely this is fundamental to threshold secret sharing - until you  
reach the threshold, you have not reduced the cost of an attack?


I'm sorry, I don't understand your sentence.  Cleversafe isn't using  
threshold secret sharing -- it is using All-Or-Nothing-Transform  
(built out of AES-256) followed by Reed-Solomon erasure-coding.  The  
resulting combination is a computationally-secure (not information- 
theoretically-secure) secret-sharing scheme.  The Cleversafe  
documentation doesn't use these terms and is not precise about this,  
but it seems to claim that their scheme has security that is somehow  
better than the mere computational security that encryption typically  
offers.


Oh wait, now I understand your sentence.  You in your sentence is  
the attacker.  Yes, an information-theoretically-secure secret- 
sharing scheme does have that property.  Cleversafe's scheme hasn't.


Regards,

Zooko

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


All your notebook belong to us

2009-08-09 Thread Jerry Leichter
Just about all notebooks shipped in the last 5 years or more contain a  
helpful bit of code in the BIOS that allows for remote tracing in case  
of theft.  Unfortunately, it's got serious security holes, allowing it  
to be used for much more nefarious purposes - like rootkits that  
survive disk reformatting and OS installation:


http://www.coresecurity.com/content/Deactivate-the-Rootkit

*What* are the guys producing this junk thinking?  It's all there  
supposedly to help customers - but I have yet to see an actual  
service offering that uses this stuff.  So right now it's all  
negatives, no positives.


  -- Jerry

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


Re: cleversafe says: 3 Reasons Why Encryption is Overrated

2009-08-09 Thread Zooko Wilcox-O'Hearn

[dropped tahoe-dev from Cc:]

On Thursday,2009-08-06, at 17:08 , james hughes wrote:

Until you reach the threshold, you do not have the information to  
attack. It becomes information theoretic secure.


This is true for information-theoretically secure secret sharing, but  
not true for Cleversafe's technique of composing an All-Or-Nothing- 
Transform with Reed-Solomon erasure coding.


CleverSafe can not provide any security guarantees unless these  
questions can be answered. Without answers, CleverSafe is neither  
Clever nor Safe.


Hey, let's be nice.  Cleversafe has implemented a storage system  
which integrates encryption in the attempt to make it safer.  They  
GPL at least some of their work [*], and they publish their ideas and  
engage in discussion about them.  These are all good things.  My  
remaining disagreements with them are like this:


1.  (The important one.)  I don't think the access control policy of  
whoever can access at least K of the N volumes of data is the  
access control policy that I want.  For one thing, it immediately  
leads to the questions that James Hughes was asking, about who is  
authorized to access what servers.  For another thing, I would really  
like my access control policy to be fine-grained, flexible, and  
dynamic.  So for example, I'd like to be able to give you access two  
three of my files but not all my other files, and I'd like you to  
then be able to give your friend access to two of those files but not  
the third.  See Brian Warner's and Jason Resch's discussion of these  
issues: [1, 2].


2.  Cleversafe seems to think that their scheme gives better-than- 
computational security, i.e. that it guarantees security even if  
AES-256 is crackable.  This is wrong, but it is an easy mistake to  
make!  Both Ben Laurie and James Hughes have jumped to the conclusion  
(in this thread) that the Cleversafe K-out-of-N encoding has the same  
information-theoretic security that secret-sharing K-out-of-N  
encoding has.


3.  Cleversafe should really tone down the Fear Uncertainty and Doubt  
about today's encryption being mincemeat for tomorrow's  
cryptanalysts.  It might turn out to be true, but if so it will be  
due to cryptanalytic innovations more than due to Moore's Law.  And  
it might not turn out like that -- perhaps AES-256 will remain safe  
for centuries.  Also, Cleversafe's product is not more secure than  
any other product against this threat.


It is hard to explain to non-cryptographers how much they can rely on  
the security of cryptographic schemes.  It's very complicated, and  
most schemes deployed have failed due to flaws in the surrounding  
system, engineering errors or key management (i.e. access control)  
problems.  Nobody knows what cryptanalytic techniques will be  
invented in the future.  My opinion is that relying on well- 
engineered strong encryption to protect your data is at least as safe  
alternatives such as keeping the data on your home computer or on  
your corporate server.  The Cleversafe FUD doesn't help people  
understand the issues better.


Regards,

Zooko

[1] http://allmydata.org/pipermail/tahoe-dev/2009-July/002482.html
[2] http://allmydata.org/pipermail/tahoe-dev/2009-August/002514.html

[*] Somebody stated on a mailing list somewhere that Cleversafe has  
applied for patents.  Therefore, if you want to use their work under  
the terms of the GPL, you should also be aware that if their patents  
are granted then some of what you do may be subject to the patents.   
Of course, this is always true of any software (the techniques might  
be patented), but I thought it was worth mentioning since in this  
case the company authoring the software is also the company applying  
for patents.


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


Re: cleversafe says: 3 Reasons Why Encryption is Overrated

2009-08-09 Thread Jerry Leichter
3.  Cleversafe should really tone down the Fear Uncertainty and  
Doubt about today's encryption being mincemeat for tomorrow's  
cryptanalysts.  It might turn out to be true, but if so it will be  
due to cryptanalytic innovations more than due to Moore's Law.  And  
it might not turn out like that -- perhaps AES-256 will remain safe  
for centuries.  Also, Cleversafe's product is not more secure than  
any other product against this threat.
Since people do keep bringing up Moore's Law in an attempt to justify  
larger keys our systems stronger than cryptography, it's worth  
keeping in mind that we are approaching fairly deep physical limits.   
I wrote about this on this list quite a while back.  If current  
physical theories are even approximately correct, there are limits to  
how many bit flips (which would encompass all possible binary  
operations) can occur in a fixed volume of space-time.  You can turn  
this into a limit based solely on time through the finite speed of  
light:  A computation that starts at some point and runs for n years  
can't involve a volume of space more than n light years in radius.   
(This is grossly optimistic - if you want the results to come back to  
the point where you entered the problem, the limit is n/2 light years,  
which has 1/8 the spacial volume).  I made a very approximate guess at  
how many bit-flips you could get in a time-space volume of a 100 light- 
year sphere; the answer came out somewhere between 2^128 and 2^256,  
though much closer to the former.  So physical limits prevent you from  
doing a brute force scan - in fact, you can't even enumerate all  
possible keys - in 100 years for key lengths somewhere not much more  
than 128 bits.


It's rather remarkable that such fundamental limits on computation  
exist at all, but physics over the last 100 years - and especially  
over the last couple of decades - has increasingly shown us that the  
world is neither continuous nor infinite; it has solid finite limits  
on almost everything.  Even more remarkable is that we've pretty much  
reached some of those limits.  For any recently designed cryptosystem,  
brute force is simply out of the question, and will remains so forever  
(unless we are very much mistaken about physics).  Moore's Law as a  
justification for using something more makes no sense.


As you point out, the story for advances in cryptographic theory is  
much more complex and impossible to predict.  That cryptographic  
advances would render the safer AES-256 at risk while AES-128  
remains secure (for now) is something no one could have predicted,  
though in retrospect some of the concerns about the key scheduling may  
have been right.  All the protocols and standards out there calling  
for AES-256 - it's obviously better than AES-128 because after all  
256 is *twice as large* as 128! - were just a bunch of nonsense.  And,  
perhaps, dangerous nonsense.

-- Jerry

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