Hi Jason,
On Wed, 2022-05-11 at 03:18 +0200, Jason A. Donenfeld wrote:
My proposal here is made with nonce reuse in mind, for things likeAlthough this makes sense the problem is that changing applications to
session keys that use sequential nonces.
do the right thing based on which situation they are in will never be
done right or soon enough. So I would focus on a solution that makes
the CSPRNGs in crypto libraries safe.
A different issue is random nonces. For these, it seems like a call to4c does sound like a decent solution, it is semantically identical to
getrandom() for each nonce is probably the best bet. But it sounds like
you're interested in a userspace RNG, akin to OpenBSD's arc4random(3). I
hope you saw these threads:
- https://lore.kernel.org/lkml/YnA5CUJKvqmXJxf2@xxxxxxxxx/
- https://lore.kernel.org/lkml/Yh4+9+UpanJWAIyZ@xxxxxxxxx/
- https://lore.kernel.org/lkml/CAHmME9qHGSF8w3DoyCP+ud_N0MAJ5_8zsUWx=rxQB1mFnGcu9w@xxxxxxxxxxxxxx/
an epoch vmgenid, all the library needs to do is to create such a mmap
region, stick a value on it, verify it is not zero after computing the
next random value but before returning it to the caller.
This reduces the race to a very small window when the machine is frozen
right after the random value is returned to the caller but before it is
used, but hopefully this just means that the two machines will just
make parallel computations that yield the exact same value, so no
catastrophic consequence will arise (there is the odd case where two
random values are sought and the split happens between the two are
retrieved and this has bad consequences, I think we can ignore that).