search

uuid6 / uuid6-ietf-draft

Next Generation UUID Formats
https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/
187 stars 11 forks source link

Fork safety #114

Closed LiosK closed 2 years ago

LiosK commented 2 years ago

Working on low-level languages like C and Rust for a couple of weeks, I've found that implementations can be vulnerable if they don't reset the state of pseudorandom number generator upon process fork. Even a CSPRNG generates identical byte sequences if the instances share the same initial state. To mitigate, it would be recommended to employ reseeding PRNG like arc4random and Rust's ReseedingRng, to draw entropy from OS every time, or to set custom fork handlers.

I have a feeling that it is a point worth noting in the best practice section because it's directly relevant to the uniqueness of generated UUIDs. But at the same time, I feel it might be out of scope because it's just one of many general caveats in using PRNGs like "seed PRNG securely." What do you think?

I created this thread because I didn't find an appropriate discussion thread.

kyzer-davis commented 2 years ago

Logical enough to me:

Possible Text Addition to 6.6 Unguessability

Implementations SHOULD utilize a cryptographically secure pseudo-random number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique"). Care should be taken to ensure the CSPRNG state is properly reseeded upon state changes, such as process forks, to ensure proper CSPRNG operation.