On May 1, 2014, at 11:56 PM, Damien Miller <djm@xxxxxxxxxxx> 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
