Hi Damien. On Tue, Dec 28, 2010 at 1:45 PM, Damien Miller <[email protected]> wrote:
> 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. > But again, we perturb it immediately afterwards, so what good is such knowledge? Also, see next comment > > > RC4 generator? In which case, pulling off a preimage attack would be > > essentially miraculous. > > > And again, is this *ever* used directly, or is it simply the input to the > 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. > So one would have to guess the MD5 output from the RC4 output in order to even pull off an attack like this. This kind of complete break would seem... unlikely... That was what I was getting at with my first query (how would a preimage attack matter in this case) > 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. > > Yeah, so without any good reason to truncate it, let's just use the whole hash, and hence, use all the entropy that we extracted from the pool. > 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. > There are arc4random_buf () calls in the kernel. Those can use the arc4random_buf_large() mechanism, can thy not? Or are the requests typically too small? -kj
