[tahoe-dev] 100 year crypto notes

[Zooko O'Whielacronx]

Hi coderman! Glad to have you here!

On Sat, May 29, 2010 at 8:10 PM, coderman <coderman at gmail.com> wrote:
> regarding AES CTR with XSalsa20, was GCM considered?

We don't need symmetric authentication—where the holder of a secret
key can both sign the data and also verify the signature on the data.
Instead we need one of two things:
 * for immutable files, we need one-time immutable authentication,
where the holder of the integrity check code can verify the
correctness of the data, but nobody (not even the original author of
the data) can cause that integrity check code to match any other file.
This is provided by a secure hash function that has collision
resistance and second pre-image resistance.
 * for mutable files, we need the digital signature property, where
the holder of the "read side" information can check that the file is
correct but can't produce new signatures, and the holder of the "write
side" information can produce new signatures. This is provided by a
digital signature algorithm, with the "read side" being the public key
and the "write side" being the private key.

So the integrated symmetric authentication in GCM mode is of no use
for either of our needs.

> as for key sizes, AES 256 might be better but only if you could
> increase rounds.

Wouldn't AES-256 arguable be better than AES-128 anyway, with standard
AES-256 (i.e. with 14 rounds)?

The only known problems with AES-256 are related key problems, which
we always completely avoid because we use strong independent keys that
an attacker can't influence. I'm a bit on the fence about it. AES-128
is arguably safer, but also arguably less safe, and it is inarguably
more efficient, and anyway it is being combined with XSalsa20 so any
weaknesses in it will most likely be unexploitable because of the
combination.

> future resistant signatures / asymmetric crypto are Hard (tm). will be
> curious to see how that's addressed...

David-Sarah has a brilliant idea about Merkle Signatures based on hash
functions. However, David-Sarah and I have a mutual agreement not to
explore awesome new crypto ideas until we finish releasing Tahoe-LAFS
v1.7. :-)

> also, any reason to prefer Salsa20 over ChaCha20?

It seems like people are standardizing on Salsa20, including DJB (the
author of Salsa20 and ChaCha20), who is using XSalsa20 in his new
crypto library NaCL:

http://nacl.cace-project.eu/valid.html

Regards,

Zooko