[imiric]

My understanding was that speed is not something you want in a UUID generator, since it makes it more susceptible to brute force attacks. Is this not the case?

I've been using Cuid2[1] in most of my personal projects (this Go implementation[2], actually), which is fast enough, but not "too fast". It's also secure, collision resistant, and has everything I would need from a UUID.

[1]: https://github.com/paralleldrive/cuid2

[2]: https://github.com/nrednav/cuid2

[stouset]

> My understanding was that speed is not something you want in a UUID generator, since it makes it more susceptible to brute force attacks. Is this not the case?

The only possible think I can think of here is using a UUID version with a small space for the random bits, such that you could accidentally collide by generating them too fast. But with something like UUIDv7, you'd need to be generating hundreds of millions of random UUIDs every nanosecond in order for that to be a realistic concern.

[sdrapkin]

cuid2 generates variable-length strings. If you want fast cryptographically strong string generation, I recommend https://github.com/sdrapkin/randstring. It will likely be faster than cuid2.

[imiric]

That doesn't address what I said. Nor explains why your package is better.

[sdrapkin]

Guid package generates guids/uuids. Your linked package generates variable length strings. These are different usecases (oh, and your benchmarks are inferior to https://github.com/sdrapkin/randstring). Nothing to argue about.

[shakna]

But this doesn't generate guid/uuids? It generates random bytes.

[sdrapkin]

Guid/uuid is defined as a 16-byte structure. Are you questioning the “byte” part, or the “random” part?

[shakna]

No, its defined to a series of specifications. [0] Ones that define an underlying structure, in bits.

You have a 16byte random string. Thats great. But it is not a UUID.

[0] https://www.rfc-editor.org/rfc/rfc9562.html

> The UUID format is 16 octets (128 bits) in size; the variant bits in conjunction with the version bits described in the next sections determine finer structure.

[imiric]

No need to argue. You just haven't addressed the point that a fast UUID generator is a security risk. I don't care about benchmarks.

And in most use cases where I'd need a UUID, I'd usually want the string representation of it.

[sdrapkin]

Fast guid/uuid generators are NOT a security risk. You want such generators to be as fast as possible, without compromising cryptographic strength.