doc: crypto.randomBytes, randomInt, randomUUID and getRandomValues continue from the saved state after a snapshot or checkpoint restore #66880

Affected URL(s)

https://nodejs.org/api/crypto.html#cryptorandombytessize-callback (also crypto.randomInt, crypto.randomFill, crypto.randomUUID, and crypto.getRandomValues of the Web Crypto API)

Description of the problem

We measure how userspace random generators behave when a process or a machine is duplicated.
For Node 24.18.0 linked against the system OpenSSL 3.5.9 (Fedora 44, Linux 7.2.11) the picture is
this; the harness and every log are available.

One guest or process saved and restored twice from the same image, the two continuations'
outputs compared block by block at equal sequence numbers: Math.random, crypto.randomBytes,
crypto.randomInt and crypto.getRandomValues are 32 of 32 blocks identical under QEMU with and
without a vmgenid device and under Firecracker with VMGenID and VMClock attached, and 14 of 14
under CRIU; a read of /dev/urandom beside them is distinct from the first block wherever the
guest kernel's vmgenid driver is present. The three crypto calls repeat because OpenSSL's
DRBG does; Math.random repeats because V8's generator is seeded once per isolate. We asked
the OpenSSL project where it places the case; its answer (2026-10-20) is that reseeding after a
restore "is currently a non-goal", not yet documented, that a documentation pull request will
be accepted and backported, and that a check-and-reseed on the VMClock generation counter would
be considered as a new feature for a future release.

What we would like to know is whether the crypto documentation should say that these calls
inherit OpenSSL's behaviour across a snapshot or checkpoint restore, so that applications
resumed from one image (SnapStart-style platforms, CRIU) know to arrange a reseed, and whether
Node would want to call RAND_poll itself on a restore signal (its own startup snapshot
feature, --build-snapshot, resumes an isolate from an image in the same way, and
crypto.randomUUID serves identifiers from a cache of 128 filled in one draw,
lib/internal/crypto/random.js).

The repeated blocks are the generators' own output; we have not looked at anything downstream.

Concretely, a sentence in the crypto documentation of the kind "these functions draw from OpenSSL's DRBG inside the process; after a snapshot or checkpoint restore the DRBG continues from the saved state until its next scheduled reseed, so an application resumed from a saved image should reseed after its own restore signal" would tell such applications what to do, and crypto.randomUUID could note its cache of 128 identifiers (lib/internal/crypto/random.js, disableEntropyCache turns it off). We can send a documentation pull request if that is welcome. The harness, the logs and the OpenSSL exchange are available on request.