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

Yann Ylavic ylavic.dev at gmail.com
Sun Jun 24 18:11:39 EDT 2018

Hi list,

I've implemented a PRNG based on D.J. Bernstein's blog entry [1] and
implementation from libpqcrypto [2].

In this design, the initial key is filled from the system's RNG
(getentropy(), getrandom(), arc4random_buf(), /dev/[u]random, ...) and
the keystream of AES-256-CTR or Chacha20 (zeroed plaintext/IV)
produces both the next key (first 32 bytes) and the random stream (a
buffer of 736 bytes which is cleared on consumption). Once the buffer
is empty, the process restarts with the new key and so on.

I wonder how I'd best handle fork()ed processes, given that with the
above design the forked key is the one that should produce the next
keystream, and obviously the parent and child processes must not use
the same one.

I would like to avoid using the system's RNG for each child process,
so was thinking of:
- in the child process, mix/xor the key with SHA256(<pid-of-child>)
and use that as the initial key;
- in the parent process, renew the key immediatly (i.e. produce the
next key and random bytes as described above) since PIDs can
potentially wrap around or come back before the buffer is exhausted
thus the renewal of the key.

Should I care about related-keys and use a KDF instead, or does this
look safe? ISTM that neither AES-CTR nor Chacha have related-key


[1] https://blog.cr.yp.to/20170723-random.html
[2] https://github.com/GaloisInc/hacrypto/blob/master/src/C/libpqcrypto/fastrandombytes/fastrandombytes.c#L15

More information about the cryptography mailing list