Hacker News Reader

Comment by imiric | Hacker News Reader

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

View on HN

> 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.

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.

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

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.

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

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

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.

No, Guid/uuids are defined as 128-bit labels used to uniquely identify objects in computer systems. This 128-bit/16-byte definition predates any RFCs that one may or may not choose to implement. I'm obviously aware of RFC 9562, and nowhere in the Guid library do I claim implementation of it. RFC 9562 is a choice, and one that should not be made blindly, or for you. It all starts with 16 random bytes. Google's uuid starts that way, and virtually every other Guid/uuid implementation. Then, on top of that building block, one may tweak additional non-random bits if the usecase truly requires it. If it does - you can do it quickly and cheaply on top of 16 random bytes. If the usecase does not require it (99% of cases), you're better off with the foundational 16 random bytes. The perspective of "your 16 random bytes do not implement RFC 9562 - BAD, BAD!" is very myopic. But if wasting bits on versions and variants is something that helps someone sleep better - they can easily and cheaply achieve that with a couple of bit ops. RFC 9562 robs developers of that choice.

Ok... But if you want to ignore the last twenty years, you should probably pick another name, because it has been used a particular way for two decades.

If you want "more choice" - use a name unbound by a tradition old enough to drink.

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.

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

Reply on news.ycombinator.com