Security Implications of "caching randomness"

There are some possible security implications of caching randomness as discussed here

Since the original ticket was about “mockability” of uuid, I’m opening this ticket for further discussion on the security implications.

The gist of the problem is:

• Using crypto.randomBytes made it extremely hard (impossible) to know previous or predict future values generated by this library
• In https://github.com/uuidjs/uuid/pull/435 this library started using a pool, which now makes it very easy to know previous and predict future values generated by looking at a memory dump

The question is should we care and why.

[simlu]

[…] How does preallocation of random bytes change anything about this general problem that you may get with multiple continuations of the same snapshot of a container?

@ctavan I’d say that the main difference is that with one approach you can easily “flush” (i.e. wait for all externally triggered operations to complete), while there is no easy way of clearing the uuid cache (which you might not even know about).

I’m no expert by any means and hence posted on stackexchange here. Let’s see if we can get someone who is an expert!

[simlu]

Sounds good. We’ve since moved away from this library to crypto.randomUUID, since uuid wasn’t working with our test library anymore after state aka caching of randomness was introduced. So I don’t really have a reason to persue this.

OK to remain closed 👍