[Fuma2514]

For #66880.

The issue measured that crypto.randomBytes, crypto.randomInt, crypto.randomFill, crypto.randomUUID and crypto.getRandomValues produce identical output across a snapshot/checkpoint restore (QEMU/Firecracker/CRIU), because OpenSSL's DRBG continues from the saved state until its next reseed, and crypto.randomUUID draws from a 128-identifier cache. The issue explicitly offered a documentation PR.

This PR adds, docs-only:

• A NOTE under crypto.randomBytes explaining the DRBG-continues-after-restore behaviour, which functions are affected, and that resumed applications should reseed after their own restore signal.
• A sentence under crypto.randomUUID about the 128-UUID entropy cache repeating after a restore and the disableEntropyCache escape hatch.

No code changes; the wording follows the sentence shape the issue proposed.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.

Caution

AgentScan found account activity patterns that may be consistent with automation. This is a heuristic, not proof that this pull request was opened by an agent or violates policy. AI-assisted contributions are permitted, but automated tooling must not open pull requests without advance approval, and contributors must personally understand, test, verify, and take responsibility for every submitted change. See the AgentScan analysis, AI use policy, and automation policy for additional context.

[MikeMcC399]

See Commit message guidelines according to the Pull requests documentation.

Your commit must contain the Signed-off-by line with your name and email address as an acknowledgement that you agree to the Developer Certificate of Origin.

[MikeMcC399]

The recommendations in:

• Guides and FAQs for first-time contributors

advise you should tackle only one issue at a time and that you should not open any new PRs until your first PR has been approved.

You already have another unapproved PR open at this time: #67341

Until the first PR has been approved and has landed in the main branch, GitHub classifies you as "first-time contributor". Each PR commit you push needs to be individually approved by team members to run in GitHub Actions CI. This causes delays for you as a contributor, and it adds to the work load for the team.

Waiting until the first PR has landed ensures that you as a contributor have experienced the complete process from PR submission to successful landing. After this has been completed, any new PRs or new commits to an existing PR are treated to rules for regular Contributors. GitHub Actions CI workflows are then run automatically without intervention by a team member.

[Fuma2514]

Closing this one for now — keeping a single open PR while the other is under review, per the first-contributor guidance. I'll reopen after the first lands. Thanks @MikeMcC399 for the pointers!