RE: [PATCH 0/2] Generate temporary files using a CSPRNG

[<rsbecker@nexbridge.com>]

On November 16, 2021 5:18 PM, brian m. carlson wrote:
> On 2021-11-16 at 15:44:33, Jeff King wrote:
> > On Tue, Nov 16, 2021 at 03:35:40AM +0000, brian m. carlson wrote:
> >
> > > For those who are interested, I computed the probability of spurious
> > > failure for the self-test mode like so:
> > >
> > >   256 * (255/256)^65536
> > >
> > > This Ruby one-liner estimates the probability at approximately 10^-108:
> > >
> > >   ruby -e 'a = 255 ** 65536; b = 256 ** 65536; puts b.to_s.length -
> a.to_s.length - 3'
> > >
> > > If I have made an error in the calculation, please do feel free to
> > > point it out.
> >
> > Yes, I think your math is correct there.
> >
> > A more interesting question is whether generating 64k of PRNG bytes
> > per test run is going to a problem for system entropy pools. For that
> > matter, I guess the use of it for tempfiles will produce a similar
> > burden, since we run so many commands. My understanding is that
> modern
> > systems will just produce infinite output for /dev/urandom, etc, but I
> > wonder if there are any systems left where that is not true (because
> > they have a misguided notion that they need to stir in more "real"
> > entropy bits).
> 
> I have specifically avoided invoking any sort of potentially blocking CSPRNG
> for that reason.  /dev/urandom is specifically not supposed to block, and on
> the systems that I mentioned, the way Go uses it would indicate that it
> should not.  There is a system, which is Plan 9, where Go uses /dev/random
> to seed an X.917 generator, and there I assume there is no /dev/urandom,
> but I also know full well that we are likely completely broken on Plan 9
> already, so this will be the least of the required fixes.
> 
> RtlGenRandom is non-blocking, and as the commit message mentioned,
> arc4random uses ChaCha20 in a non-blocking way on all systems I could find,
> except MirBSD which uses RC4, also without blocking.  Linux's CSPRNG is also
> non-blocking.
> 
> I've also looked at Rust's getrandom crate, which provides support for
> various other systems, and I have no indication that any of the interfaces I've
> provided are blocking in any way, since that crate would not desire that
> behavior.  Looking at it just now, I did notice that macOS supports
> getentropy, so if I need to do a reroll, I'll add an option for that.
> 
> So I don't think we're likely to run into a problem here.  If we do run into
> systems with that problem, we can add an option to use libbsd, which
> provides arc4random and company (using ChaCha20).  The tricky part is that
> when using libbsd, arc4random is not in <stdlib.h> (since that's a system
> header file) and is instead in <bsd/stdlib.h>.  However, it's an easy change if
> we run into some uncommon system where that's the case.
> 
> If we don't like the test, we can avoid running it by default on the risk of
> seeing breakage go uncaught.

Adding these dependencies are also a problem. libbsd does not port to NonStop. GO is not available yet. Please stay at least somewhat POSIX-like. Begging because I do not want to lose git.
-Randall