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 _______________________________________________ tahoe-dev mailing list tahoe-dev@allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev