[tahoe-dev] timeouts

[Jason Resch]

David-Sarah Hopwood wrote:
> Jason Resch wrote:
> > james hughes wrote:
> >> 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."
> >>>
> >>>> [3] http://dev.cleversafe.org/weblog/?p=63
> >>>
> >>> 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.
> > 
> > With a secret sharing scheme such as Shamir's you have information
> > theoretic security.  With the All-or-Nothing Transform and dispersal
> > the distinction is there is only computational security.  The practical
> > difference is that though 2^-256 is very close to 0, it is not 0, so
> > the possibility remains that with sufficient computational power useful
> > data could be obtained with less than a threshold number of slices.
> > The difficulty of this is as hard as breaking the symmetric cipher
> > used in the transformation.
>
> So I'm confused. You understand perfectly well that the dispersal+AONT
> scheme depends on the computational security of the cipher [*], but you
> use the risk of a computational attack on the cipher as an argument
> against encryption. Isn't that part of the argument in the blog post
> (quoted by Zooko above) just completely invalid, and in need of
> retraction?

We have added some clarification in the form of an "update" to the original post that I think addresses your concern.

http://dev.cleversafe.org/weblog/?p=63

>
> Yes, I realise that a later post argued that you were talking about
> attacks against asymmetric encryption. But:
>
> a) The title of the original post is not "3 Reasons Why Asymmetric
>    Encryption is Overrated." The criticism of encryption in general
>    is repeated several times in the subsequent posts, without making
>    any symmetric vs asymmetric distinction.

True, the original post lacked technical details, which is why I wrote the follow up responses to provide the technical background and support for the points made in the original.

I should also note that the points made in that post do not revolve entirely around issues with asymmetric encryption.  Symmetric cryptosystems still have the issue of key management: How does one manage, store, protect and dispense encryption keys when asymmetric encryption is not used?  Are they protected by password based encryption systems?  If so, how is the password kept simultaneously secure against brute force attacks and our imperfect memories?  Etc.

>
> b) Suppose that we accept for the sake of argument the negative opinions
>    expressed about the long-term security of asymmetric schemes. Then
>    any benefits of CleverSafe's approach in that respect would apply
>    also to other systems using conventional symmetric encryption with
>    a long-term key, if they either used symmetric cryptography
>    exclusively, or only used shorter-term asymmetric authentication
>    keys (subject to point c) below). In other words, it's not the use
>    of dispersal+AONT that is the relevant factor here.

That depends on how the keys are managed in those other conventional symmetric encryption systems you mention.  There's been much criticism regarding our security focused on how we store data/keys, but no one has yet described how keys are stored in the systems they use.  Of course we are used to pretending the location storing keys has perfect confidentiality and reliability when evaluating the security of a system, but in practice that is never true.

Furthermore, if we consider every machine as an equal and constant cost associated with compromising it (C), then dispersed systems are more difficult to compromise then a conventional system in which there are two machines, one storing the encrypted data and one storing the key.  The conventional approach always has a cost of 2 * C to compromise, while dispersed systems can have K*C cost, where K is the threshold.

>
> c) If an asymmetric scheme used for authentication is later broken,
>    it is not clear that the new attack will not be usable against
>    previously recorded sessions to obtain their session keys.
>    Whether it can depends on the kind of attack -- but a direct
>    attack against the private->public key one-way function, such as
>    an advance in factoring, for example, probably can be used in this
>    way. So CleverSafe's system -- using asymmetric cryptography only
>    for authentication -- would be just as vulnerable as systems using
>    asymmetric encryption in this situation.

If Ephemeral Diffie-Hellman were used, forward security remains in the event the asymmetric algorithm used for digital signatures is broken, however if the discrete logarithm problem is solved, then the guarantees of EDH are lost.  The only secure method for transport encryption that doesn't depend on asymmetric cryptography that I am aware of is quantum encryption, which one would have to use if they feared that both their traffic was being intercepted and recorded near the origin and a future break in the discrete logarithm problem.

Interesting points and ideas.

Regards,

Jason
>
>
> [*] In fact, the specific scheme described in
>     <http://dev.cleversafe.org/weblog/?p=111> is *exactly* as secure
>     as the cipher, used in whatever encryption mode is employed in
>     step 2 under the heading "All-Or-Nothing Transform". Note that
>     this applies to any attack against the cipher (assuming that the
>     conditions of the attack, e.g. amount of ciphertext and known
>     plaintext available, are satisfied), and not just brute force.
>
>     (Some contributors to the discussion seem to have been confused
>     by the difference between security properties of secret sharing
>     vs dispersal. A k-of-n dispersal scheme only guarantees that
>     k shares are *sufficient* to retrieve all of the input; not that
>     k shares are *necessary* to retrieve any part of the input.
>     Since the first k shares in the dispersal scheme used by the
>     CleverSafe system are just 1/kth slices of the input, there is
>     obviously no additional security provided by the dispersal scheme
>     that could frustrate attacks on the cipher in this case.)
>
> -- 
> David-Sarah Hopwood  ?  http://davidsarah.livejournal.com
>