Jacob Champion <[email protected]> writes: > On Fri, Oct 3, 2025 at 5:11 AM Joe Conway <[email protected]> wrote: >> That RFC appears to be specific to UUIDv4, but assuming that advice is >> generally >> applicable to UUIDs in general it seems to mean we are off the hook when it >> comes to FIPS with respect to UUIDs. > > The most recent RFC still says that [1]. And it doesn't appear to > mandate the use of a CSPRNG at all, so it'd be unfortunate if UUIDs > were bound by FIPS considerations... but my opinion has no effect on > whether they're bound in practice.
It doesn't mandate (MUST) a CSPRNG, but it strongly recommends (SHOULD) it (unless unavailable) in the best practices section (https://www.rfc-editor.org/rfc/rfc9562.html#name-unguessability): 6.9. Unguessability Implementations SHOULD utilize a cryptographically secure pseudorandom number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique"). The exception is when a suitable CSPRNG is unavailable in the execution environment. Take care to ensure the CSPRNG state is properly reseeded upon state changes, such as process forks, to ensure proper CSPRNG operation. CSPRNG ensures the best of Sections 6.7 and 8 are present in modern UUIDs. - ilmari > --Jacob > > [1] https://www.rfc-editor.org/rfc/rfc9562.html#name-security-considerations
