pitdicker
commented
6 years ago I think this could work well as part of ReseedingRng.
For WIPEONFORK to work you need to check some value against zero, and need to have a seeding RNG. ReseedingRng already needs to check a bytes_generated counter against generation_threshold, and has a reseeder. We would just have to invert the counter and back-off logic. That may even make it slightly faster, because comparing against 0 is slightly faster than checking against a value.
Is failing to reseed after a fork a case we want to handle, or exceedingly rare? We are talking here about a feature for a very recent Linux kernel version, and for OpenBSD. Both have an OS RNG that is supposed to be infallible. And if ReseedingRng is combined with ReseedWithNew it will have JitterRng as a backup. So I think we do not need to do something extra to the error handling ReseedingRng already has.
Advantages of using a custom wrapper:
- Two pieces of functionality are nicely separated.
- It is possible to have only
WIPEONFORKprotection without the need to increment a counter.
Advantages of using ReseedingRng instead of a custom wrapper:
- I think there is an overlap in the situations where you want the extra fork safety, and the extra defense of occasionally reseeding.
- No extra performance overhead when you want to have both reseeding and
WIPEONFORKprotection.
dhardy
burdges
We could maybe make use of this, e.g. as a wrapper around a CSPRNG: https://aws.amazon.com/blogs/opensource/better-random-number-generation-for-openssl-libc-and-linux-mainline/
Unfortunately it sounds like it's only available on one platform.