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

WIPEONFORK [Linux] #59

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions