4 ms·
GUIDs are Microsoft's implementation of UUIDs. UUIDs are long enough (128 bits) that you can generate them randomly and be confident in never getting a collisio
by rspeer 10y ago
GUIDs are Microsoft's implementation of UUIDs. UUIDs are long enough (128 bits) that you can generate them randomly and be confident in never getting a collision.
That's what UUID4 is -- all but six bits (that's 122 bits) are completely random. Checking for UUID4 collisions is the height of paranoia. It's basically checking whether your PRNG broke.
So your second recommendation is basically the same as the article's, and contrary to the first. Comparing UUIDs is not that expensive, but as expensive as it has to be for a key that will never collide.
- toast0 10y agoYou'll never know if your PRNG is broken if you just assume it's not and don't check. Well, you might find out later, and have a lot of tricky cleanup.
- justusw 10y agoComparing UUIDs is cheap, but avoiding non-constant-time compares is a necessity. So the usual for loop with an early exit when two bytes don't match up is poison. A web application could become susceptible to timing attacks. This is a good article that helped me understand and mitigate the vulnerability: https://codahale.com/a-lesson-in-timing-attacks/ https://codahale.com/a-lesson-in-timing-attacks/
- nitrogen 10y agoYou also have to protect against an attacker guessing your next PRNG output, which is highly likely for non-crypto PRNGs even if they'll never collide with themselves. So always use the secure RNG from your language or OS for generating UUIDs.