Regarding the optional OpenSSL integration for the portable version

[Brent Cook]

On May 1, 2014, at 11:56 PM, Damien Miller <djm at mindrot.org> wrote:

> On Thu, 1 May 2014, Brent Cook wrote:
> 
>> Hi,
>> 
>> I have been working on a portable LibreSSL build tree for a little
>> while to test the waters: http://github.com/busterb/libressl
>> 
>> Someone noticed an issue with the arc4random
>> implementation that I originally grabbed from libbsd
>> https://github.com/busterb/libressl/issues/1
>> 
>> So, I looked at how OpenSSH handles it, and noticed that it uses the
>> random functions from OpenSSL unconditionally to seed the state of its
>> version of arc4random.
> 
> I haven't ported the no-OpenSSL changes yet and haven't thought about
> how I'll handle arc4random.
> 
> I'll probably make an explicit arc4random_stir() function that we can
> call in various places. OpenBSD has put some effort in to ensure that
> the kernel PRNG is available in pretty much any context (privileged,
> unprivileged, in chroot without devices, etc.) and AFAIK no other OS
> does this.
> 
> IMO the libbsd code and yours both do one risky thing: for OpenSSH at
> least, the right response to not being able to read KEYSIZE bytes from
> /dev/urandom for the initial seeding is to fatal()/abort(). Obviously
> this isn't likely to be popular in a generic library, but it's the
> only safe thing to do.

Thanks for the feedback. I certainly would not want anyone to generate certificates with entropy based only on random stack + PID + time, which would effectively be just stack + PID + short time range since certificates are timestamped.

It looks like I need to connect up the state of the arc4random implementation to the RAND_poll()/status()/bytes() methods so they fail properly and return bad status if urandom could not be read.

> -d