> > 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?
>
> arc4random_buf_large() is not exported as an API; this is intentional.
>
> If you do arc4random_buf_large() for a small buffe
> > 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 typ
Hi Damien.
On Tue, Dec 28, 2010 at 1:45 PM, Damien Miller 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
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 ou
How would a preimage attack matter in this case?
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?
And again, i
On Mon, 27 Dec 2010, Kjell Wooding wrote:
> The OpenBSD random number subsystem uses an in-kernel entropy pool. This
> data isn't used directly. When entropy is requested, the contents of the
> pool are hashed with MD5, and the massaged output used to seed an RC4 PRNG.
>
> In looking at the code,
On Mon, Dec 27, 2010 at 8:07 PM, Kjell Wooding wrote:
> My question: Why? What exactly are we protecting against, and is this really
> protection? (the comment indicates "some recognizable output pattern, but
> that means little to me as is) Can we really be sure it doesn't make things
> worse?
>
The OpenBSD random number subsystem uses an in-kernel entropy pool. This
data isn't used directly. When entropy is requested, the contents of the
pool are hashed with MD5, and the massaged output used to seed an RC4 PRNG.
In looking at the code, however, I notice we actually fold the MD5 output in
