On Thu, Jun 10, 2010 at 05:34:12PM +0100, Samuel Neves wrote: > > Why not use Comb4P with some normal KDF, such as PBKDF2? Comb4P is > already being planned for hashing, anyway.
Hmm. Using a Comb4P hash here did not occur to me. Some definite PBKDF2 advantages: - Supports arbitrary sized inputs - Internal state is as large as the internal PRFs; in the typical case of HMAC, that's however big the internal hash's state is. For a Comb4P 512+512 hash, that would be at least 1024 bits if not more, which is certainly plenty by any stretch. - Totally standard and well-specified (which I think is an advantage not to be underestimated). - 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. Immediately obvious downsides: - Perhaps slower than what is really necessary, especially if iteration is used. Don't know if this is relevant to the use case. - Doesn't natively support multiple different tagged inputs for salting/parameterization. They would instead have to be combined using an invertible (ie, unambigious) encoding and all placed into the salt. Obnoxious, but then again few (if any) KDFs support this natively, so we're stuck with it regardless. -Jack _______________________________________________ tahoe-dev mailing list tahoe-dev@allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev