[tahoe-dev] What is the 100 year crypto KDF?

[Jack Lloyd]

On Thu, Jun 10, 2010 at 10:14:07AM -0700, Chris Palmer wrote:
> Jack Lloyd writes:
> 
> > - Built-in iteration support. I don't know if it is worth using
> >   necessarily, considering the inputs will all be high-entropy rather
> >   than human-{chosen,memorized,postitnoted} passwords, but it _may_
> >   still offer benefits.
> 
> This is why I wonder if a KDF is necessary at all. As I understand it, there
> is no security need to whiten, stretch, mangle, or noodlize the output from
> (e.g.) /dev/urandom. Am I wrong, or only wrong for a specific Tahoe-LAFS
> scenario?

Most of the keys are not being generated on the fly, but are derived
from some other data, and for usability reasons we have restrictions
on how long they can be. For instance file contents are encrypted by a
key generated by hashing the contents; this provides convergent
encryption, which is a useful property. But it means we only have
access to (currently 256 bits of keying material (the SHA-256 hash
output)), and even if we moved to SHA-512 for this purpose we still
wouldn't have enough bits for everything we need.

Some keys are in fact random, but we don't want to make them too long,
because that directly makes Tahoe capability strings longer, which
causes usability problems, as described in ticket 217 [1].

[1]: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/217