Security Implications of Caching Randomness

Question

Is it a bad idea to cache randomness in the general case? My feeling is yes, but I'm having a hard time articulating why.

Scenario:

A programming language of your choice (e.g. node) uses a native call to generate random bytes (e.g. for creating a uuid). It is very hard to predict the random bytes even with access to the operating system.

The call has overhead and to speed up execution time a memory cache is introduced. So instead of retrieving random bytes from the OS as they are needed (i.e. every time a uuid is needed), they are only retrieved when the cache is empty.

The random bytes are now in memory of the running program. In theory they can be accessed by inspecting the memory. In the general case (where this is done by a library and one has no idea how the randomness is being used), is this a bad idea? If so, why?

Disclaimer: I'm really looking for a good argument for this github issue https://github.com/uuidjs/uuid/issues/527 [~36m weekly downloads]

Answer 1

Assuming you have plenty of good, random bits, the pitfalls associated with caching randomness all stem from the potential for malicious access. That is, there isn't anything inherently wrong with caching randomness, however it creates a larger attack surface. If the developers have reason enough to believe that the memory is a safe storage location then this approach is safe.

One way of thinking about this is looking back at the historical use of the one time pad (OTP). OTP was used by militaries to encrypt and decrypt messages and is still considered unbreakable to this day. The codes in this case were stored on paper (analogous to your cache). However, the rules required for this process to be unbreakable include:

• The key must be truly random.
• The key must be at least as long as the plaintext.
• The key must never be reused in whole or in part
• The key must be kept completely secret.

As long as you can guarantee the same for your cached random bytes, then the randomness is fine.