4 ms·

If you need the IDs to be unique per machine just use a unique-per-machine identifier - like the MAC address of the network card. Then use a counter that increm

by inglor 11y ago

If you need the IDs to be unique per machine just use a unique-per-machine identifier - like the MAC address of the network card. Then use a counter that increments by 1 for each generated ID. If you need to be resilient to failures - just checkpoint every 10K (or 100K) numbers and add 10K to the starting number when you reboot after failure. No collisions ever. Seriously - I don't understand why people would overthink it that much. Not to mention OP talks about MD5 and SHA1's security issues - well guess what? MD5 was never meant to be used for crypto - just validation. Saying it's bad at being used for cryptography like that is like saying cats are a bad war time weapon - true but meaningless.

robrenaud 11y ago
What if your MAC addresses aren't spread that far between each other?
- inglor 11y ago
  What about it? Remember, we're no longer using a hash function on anything - we don't want the numbers to be uniformly spread on any range - just unique.
mikeash 11y ago
No collisions ever, unless your MAC addresses collide. This could happen due to using VMs, or if somebody reconfigures the MAC to a colliding value, or if it turns out that your NIC manufacturer was lazy/incompetent and gave you a non-unique MAC. I agree, I don't understand why people would overthink it this much. Grab N bits from /dev/urandom (where N=128 is fine, and N=256 will quiet any paranoia) and call it done. In the unlikely event that generating unique IDs becomes a performance bottleneck, then you can look into something slightly more complex. Reading N*M bytes (where M is maybe 10-100) in one call and caching the surplus should suffice.
geofft 11y ago
> MD5 was never meant to be used for crypto - just validation. I'm not sure what you mean by this. Quoting from the author of MD5 in the RFC specifying it (https://tools.ietf.org/html/rfc1321 https://tools.ietf.org/html/rfc1321): "The MD5 algorithm is intended for digital signature applications, where a large file must be 'compressed' in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA."

by inglor 11y ago

robrenaud 11y ago

What if your MAC addresses aren't spread that far between each other?

inglor 11y ago
What about it? Remember, we're no longer using a hash function on anything - we don't want the numbers to be uniformly spread on any range - just unique.

mikeash 11y ago

No collisions ever, unless your MAC addresses collide. This could happen due to using VMs, or if somebody reconfigures the MAC to a colliding value, or if it turns out that your NIC manufacturer was lazy/incompetent and gave you a non-unique MAC. I agree, I don't understand why people would overthink it this much. Grab N bits from /dev/urandom (where N=128 is fine, and N=256 will quiet any paranoia) and call it done. In the unlikely event that generating unique IDs becomes a performance bottleneck, then you can look into something slightly more complex. Reading N*M bytes (where M is maybe 10-100) in one call and caching the surplus should suffice.

geofft 11y ago

> MD5 was never meant to be used for crypto - just validation. I'm not sure what you mean by this. Quoting from the author of MD5 in the RFC specifying it (https://tools.ietf.org/html/rfc1321 https://tools.ietf.org/html/rfc1321): "The MD5 algorithm is intended for digital signature applications, where a large file must be 'compressed' in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA."