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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Nov 16, 2021, 22:17 UTC
Message-ID: <YZQuDVMRx6hGEbpe@camp.crustytoothpaste.net>
In-Reply-To: <YZPR4Ya1ocWvKbAf@coredump.intra.peff.net>

On 2021-11-16 at 15:44:33, Jeff King wrote:

Show 24 quoted lines

> 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.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA