openssh unix dev - May 2014 - Regarding the optional OpenSSL integration for the portable version

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.

Regarding the new ?build without OpenSSL? flag here:
http://article.gmane.org/gmane.os.openbsd.cvs/130612

it would be nice to have some feedback on this modified version of the OpenSSH
portable arc4random that I incorporated, which seeds itself in the same manner
as libbsd?s version:

libbsd?s version: http://cgit.freedesktop.org/libbsd/tree/src/arc4random.c

modified version:
https://github.com/busterb/libressl/blob/master/crypto/compat/arc4random.c

If the seed function here doesn?t seem suitable, perhaps we could come up with a
common arc4random implementation that works portably for LibreSSL and OpenSSH,
which also does not depend on OpenSSL?s random number generation.

 - Brent

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.

-d