5 ms·

This seems like it could be useful, but > Cryptographically secure source of randomness, if possible I don't think this should be a goal. If this is for IDs,

by wgj 8y ago

This seems like it could be useful, but > Cryptographically secure source of randomness, if possible I don't think this should be a goal. If this is for IDs, you usually want to optimize for speed of generating IDs and evenness of distribution (aside from merely reducing collisions.) The top answer at below link has a good top list of hash algorithms. None of them are cryptographic. https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed https://softwareengineering.stackexchange.com/questions/4955...

exyi 8y ago
IMHO, in most cases you don't need performance nor "security", if you simply generate IDs for some documents in DB that generating ID is totally negligible in comparison with storing that on disk. In case it is a performance bottleneck you'll quickly find that out, it's probably very easy to get some flamegraph and see the crypto generator here. However, in case you need security, people quite likely to miss that out until something gets wrong... It's certainly a compromise, but I like their choice
- wgj 8y ago
  What are you securing? It's a cryptographic hash of what?
  - exyi 8y ago
    It's not hash, you probably want to prevent bad guys from making you ID collisions.
- BugsJustFindMe 8y ago
  It seems kinda like their way of saying "if your random sections collide, then you're boned", which of course isn't the same as what they said.
ivan_gammel 8y ago
I'd disagree with you on both. ID generated with a secure source of randomness can be used as an opaque access token, e.g. to share some temporary object via e-mailed link. At the same time, optimizing the speed of generation that much is not necessary in many use cases, when objects are created much less often than accessed - performance impact won't be noticeable. It will likely be faster than another common choice for the source of IDs - a sequence in remote database.
- dchest 8y ago
  I agree with your point in general (regarding CSPRNG), but ULID turns out to be not suitable as opaque access token since it increments the random part if it's generated in the same millisecond range. So, if someone gets this token, they can try incrementing it and checking if they can get access to something using this derived token, and will get access if another token was generated at the same millisecond. In fact, this is dangerous and should be mentioned in the documentation.
  - ivan_gammel 8y ago
    Good point, thank you! This problem can be mitigated by using random increments. If initial random value is 79-bit and increments are in range [M, 2^n], where M>1 and n<=78 , by varying values of M and n you can find the right balance between density and security. This way server may also detect brute force attacks on IDs with specific millisecond value (by simply catching the misses) and progressively increase response time to make them ineffective.
    - ngrilly 8y ago
      github.com/oklog/ulid does something similar: https://godoc.org/github.com/oklog/ulid#Monotonic https://godoc.org/github.com/oklog/ulid#Monotonic
jmtulloss 8y ago
I suspect they want a "good" random generator, and a cryptographically secure generator is a known good generator. Without one you don't have a definition of random and you may end up with an unacceptably high chance of collisions.

by wgj 8y ago

exyi 8y ago

IMHO, in most cases you don't need performance nor "security", if you simply generate IDs for some documents in DB that generating ID is totally negligible in comparison with storing that on disk. In case it is a performance bottleneck you'll quickly find that out, it's probably very easy to get some flamegraph and see the crypto generator here. However, in case you need security, people quite likely to miss that out until something gets wrong... It's certainly a compromise, but I like their choice

wgj 8y ago
What are you securing? It's a cryptographic hash of what?
- exyi 8y ago
  It's not hash, you probably want to prevent bad guys from making you ID collisions.
BugsJustFindMe 8y ago
It seems kinda like their way of saying "if your random sections collide, then you're boned", which of course isn't the same as what they said.

ivan_gammel 8y ago

I'd disagree with you on both. ID generated with a secure source of randomness can be used as an opaque access token, e.g. to share some temporary object via e-mailed link. At the same time, optimizing the speed of generation that much is not necessary in many use cases, when objects are created much less often than accessed - performance impact won't be noticeable. It will likely be faster than another common choice for the source of IDs - a sequence in remote database.

dchest 8y ago
I agree with your point in general (regarding CSPRNG), but ULID turns out to be not suitable as opaque access token since it increments the random part if it's generated in the same millisecond range. So, if someone gets this token, they can try incrementing it and checking if they can get access to something using this derived token, and will get access if another token was generated at the same millisecond. In fact, this is dangerous and should be mentioned in the documentation.
- ivan_gammel 8y ago
  Good point, thank you! This problem can be mitigated by using random increments. If initial random value is 79-bit and increments are in range [M, 2^n], where M>1 and n<=78 , by varying values of M and n you can find the right balance between density and security. This way server may also detect brute force attacks on IDs with specific millisecond value (by simply catching the misses) and progressively increase response time to make them ineffective.
  - ngrilly 8y ago
    github.com/oklog/ulid does something similar: https://godoc.org/github.com/oklog/ulid#Monotonic https://godoc.org/github.com/oklog/ulid#Monotonic

jmtulloss 8y ago

I suspect they want a "good" random generator, and a cryptographically secure generator is a known good generator. Without one you don't have a definition of random and you may end up with an unacceptably high chance of collisions.