[tahoe-dev] 100-year cryptography

[Zooko O'Whielacronx]

On Wed, Mar 10, 2010 at 4:28 PM, Samuel Neves <sneves at dei.uc.pt> wrote:
>
> One solution is, of course, to adopt parallel modes of operation (e.g., tree hashing) in this case.

Tahoe-LAFS already (in v1) uses tree hashing for (almost) everything.
We will make sure it uses highly parallelizable structures in v2 for
either almost everything or for everything.

(The one possible exception is: we might offer an *optional* normal
linear hash as a double-check to detect bugs in the implementation of
the tree hash. :-))

> This is not to say SHA-512 is a bad idea. If we can assume it will remain secure 100 years from now, we can replace it with (faster?) SHA-3 anytime we want.

Yes one of the interesting things that I learned by thinking about
"100 year security" is that the properties of integrity,
unforgeability, and confidentiality age differently from one another.

If you start to think that someone may be able to collide the secure
hash function that you used, you can use a better hash function and
generate new caps to all of your files and then start using the new
caps. As long as you do this *before* anyone *actually* generated a
collision for any of your files, you preserve integrity.

If you start to think that someone may be able to break your digital
signature algorithm, you can start using a new digital signature
algorithm and stop respecting signatures from the old one. Again, if
you acted before the attacker did, then you preserve unforgeability.

But, if you start to think that someone can crack the cipher that you
used in the past, there's not much you can do! You can issue requests
to storage servers saying "Would you please go ahead and throw away
that old ciphertext.", but as Chris Palmer has pointed out, there is
really no way to guarantee that all copies of the old ciphertext are
gone. Consider that your attacker may well have gone ahead and
collected old copies of your ciphertext years ago and kept them stored
away for just such an eventuality. Or more likely that your attacker
can buy copies of your old ciphertext from someone who *did* collect
them back when they were fresh.

So one consequence of this way of thinking is that we should be extra
*double* super conservative on encryption. Fortunately it is easy,
efficient, and well-studied to use a combiner of XSalsa20+AES-128. :-)

> The fact is, while 100-year security is an idea worth pursuing, no one (but the most paranoid people) will use an overly slow system, if there are faster alternatives.

Agreed! We never want to incur bad performance if we can help it,
because we want Tahoe-LAFS to be widely used.

> Today, LAFS is (relatively) a novelty. In 5-10 years, when it begins to be acceptably fast, will it still be?

I'm not sure if I follow this. Tahoe-LAFS is already acceptably fast
for many uses. We know that it is not acceptably fast for some other
uses, and we know why it is not, and so far the reasons why it is not
are mostly to do with network behavior and not with cryptography. (The
exception is RSA keypair generation, which means it takes a lot of CPU
cycles to generate a new mutable file or directory and which needs to
be fixed by the application of new cryptography.)

> Or will everyone already be using solution X, Y or Z?

I really hope to make it so that one of our best competitors when we
are writing future versions of Tahoe-LAFS is older versions of
Tahoe-LAFS. :-) I.e., we already try to satisfy (some) users today and
we hope to keep satisfying them continuously between now and then.

Thank you for your comments! You happen to be an expert on this stuff
(http://eden.dei.uc.pt/~sneves/ ), so I hope you keep paying attention
and catch any mistakes. :-)

Regards,

Zooko