Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Jul 2018 10:49:44 -0400
From: Rich Felker <>
Subject: Re: arc4random/csprng

On Tue, Jul 03, 2018 at 04:18:37PM +0200, Luca Barbato wrote:
> On 02/07/2018 22:39, Rich Felker wrote:
> > I haven't followed what's been happening with posix_random lately, but
> > glibc has adding the arc4random interfaces and it seems reasonable
> > that we should too, with the easy option to add the posix_random name
> > for it and whatever interface details POSIX decides on.
> > 
> > The glibc implementation looks like it's essentially CTR mode AES.
> > This is probably a pretty good choice, but unless there are strong
> > reasons not to I'd probably rather go with Hash-DRBG or HMAC-DRBG
> > utilizing the existing SHA-256 code we already have. That would avoid
> > the need to write or import any new cryptographic code (and the
> > associated risks) and keep the size cost minimal. This seems better
> > for forward-secrecy too, but I'd like to better understand the
> > conditions under which Hash-DRBG and HMAC-DRBG provide
> > forward-secrecy.
> From what I read the various BSDs opted for ChaCha20, not sure which are
> the trade-offs for this choice thought.

Yes, we've been looking at chacha20 based solutions on IRC since
measuring that HMAC-SHA256-DRBG would likely be as slow as asking the
kernel for entropy (though still better because it works on kernels
where we can't do that).

I'm not sure what the BSDs do about forward secrecy with chacha20,
since straight CTR-mode stuff clearly fails. But I think DJB's design
here can be applied to get forward secrecy:


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.