2 ms·
> Random IDs (Was: Use 256-bit random numbers): Remains: use 256-bit random numbers. 256-bit random identifiers are overkill. 122 random bits (as in a GUID) sh
by quotemstr 11y ago
> Random IDs (Was: Use 256-bit random numbers): Remains: use 256-bit random numbers.
256-bit random identifiers are overkill. 122 random bits (as in a GUID) should still be more than sufficient. Size is important for IDs because people whine about the storage overhead. A 256-bit identifier requirement may unfortunately convince some people that it's better to use much smaller, non-random identifiers, and that'd be a shame.
- jacobparker 11y agoThe 256 bit advice is golden if only to encourage people to not use GUIDs in these scenarios. GUIDs are unique--not necessarily unguessable. Any implementation may be using a CSPRNG but in general you shouldn't rely on that (unless its your implementation and its a documented behaviour.) Honestly I've found this (perhaps pedantic) mistake to be highly correlated with other badness/sloppiness. GUIDs are awesome, and can be used in plenty of places near crypto, like OAuth 1.0-style nonces, IDs for public keys... just don't use them for their "randomness".
- quotemstr 11y agoOf course you have to be aware of your implementation. On Windows, UuidCreate returns unguessable GUIDs. (COM security depends on this property.) libuuid provides similar guarantees if /dev/urandom is available. But anyway, my point wasn't that you should necessarily use GUIDs for unguessable IDs (although that's fine if you're using real randomness), but that 256 bits is overkill and that 128-ish is good enough.