Hi Damien.

On Tue, Dec 28, 2010 at 1:45 PM, Damien Miller <djm@mindrot.org> wrote:

quoted text
> 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


quoted text
>
> > 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)

quoted text
> 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.


quoted text
> 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