[Cryptography] Fast-key-erasure RNG and fork()ing

Tom Mitchell mitch at niftyegg.com
Wed Jun 27 19:31:26 EDT 2018

On Tue, Jun 26, 2018 at 7:40 PM, james hughes <hughejp at me.com> wrote:
> On Jun 24, 2018, at 4:11 PM, Yann Ylavic <ylavic.dev at gmail.com> wrote:
> I wonder how I'd best handle fork()ed processes,
> ......

> Simple. Use an RNG that does not keep state in the application.
>    - Use a hardware RNG
>    - Use a kernel level RNG that does not provide bits until it has
>    sufficient entropy.
> Confused.

Slightly confused as well.
Fork by design keeps a lot of state and the state of the PRNG is only one
interesting bit of state.
Everything other than the return value is the same, everything.
Both the parent and the child can call for a system *rand value for a new
One or both....  both because some history might leak from parent to child.
Copy on write can help.  malloc() and friends might hide a lot of malloc()
fragmented cruft that is passed from parent to child to child to child...
i.e. objects not yet written to are in the map for inspection.  Garbage

Benchmark fork() and tidy(all) vs fork(); exec()  and also vfork(); exec()

The very first parent can fork(); exec(generator)  where the generator can
listen for a localhost connection and
return random bits on demand.  A generator can be quick and if the system
*rand() services are suspect
it can ignore them or if they are golden use the heck out of them. It can
be poked with signals to fetch hardware
random bits from some other good local or far service.  If a PRNG is
sufficient this might  isolate this design problem
into one object.

It might be possible to build a generator using tricks that node uses to be
such a  quick web server.

Fork is safe in some constrained well managed cases.
What if the parent never sees random bits  or other secrets and simply
forks() to get work done knowing that it is safe to
do so because there are no secrets in the parent to worry about.   Now the
child can make a call to a system *rand device
check the return value so it knows it got enough and then go to work.

What happens if there are multiple copies or the parent/ child exits with
an error.   What process can wait()
to  catch child exit/death signals (no zombies or orphans please)?   Is an
orderly system shut down well managed?
How does this design play in a migrating VM or is this a documented out of
scope issue.   i.e. is it cloud safe.

How fast must it be?

  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180627/de72c0db/attachment.html>

More information about the cryptography mailing list