On Tue, 28 Dec 2010, Kjell Wooding wrote: > How would a preimage attack matter in this case?
It gives you knowledge of the collection pool, which is what the very thing the design is supposed to avoid. > Even if I could pull one off, (i.e. guess the contents of the entropy pool > based on the output of the hash), we perturb it again right afterwards. > Furthermore, how would this be any different than choosing just the upper or > lower half? I don't know; like I said, most cryptographers that I have spoken to prefer truncation to folding. > And again, is this *ever* used directly, or is it simply the input to the > RC4 generator? In which case, pulling off a preimage attack would be > essentially miraculous. It is used to seed RC4. In the past it used to be used for other things, but we switched them over to RC4 a while back. > In any case, if there is not a good reason to keep it (since it's not > standard practice), why not eliminate it? I just don't see what it > accomplishes. I think the choice would be to truncate or to use the whole hash. > Sure, it may be worth investigating another hash function. Maybe even > another stream cipher for use with the PRNG, > but we should be clear about what the requirements for such a hash / cipher > should be. > > Certainly, speed is a factor for both. RC4 is hella fast, but since we need > to dump k*256 bytes of keystream every time, something else may end up being > faster. This matters for userspace, but not for the kernel. We only start up one RC4 instance, so RC4's low key agility doesn't really bother us. -d
