Live data from Hacker News

Fast cryptographically safe GUID generator for Go

github.com

31–40 of 43 posts

Re: Fast cryptographically safe GUID generator for Go

#31

Advertising any UUID/GUID generator as cryptographically secure, or relying on it to be so, is a mistake, in my opinion. You use a UUID when you need a universally unique ID whose guessability properties are not a critical security requirement. While the V4 UUID spec (which this package does not implement, but most users might assume it does) states that a UUID implementation SHOULD be cryptographically secure [1], i…

The vast majority of Golang developers would benefit from using Guid library instead of UUID library. It’s substantially faster in all cases, more secure (by 2^6) and has more functionality.

For random token-as-string generation Golang developers should be using https://github.com/sdrapkin/randstring instead of crypto/rand.Text (faster and more flexible).

Re: Fast cryptographically safe GUID generator for Go

#32
post #28

Earlier quoted context omitted.

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.

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.

Re: Fast cryptographically safe GUID generator for Go

#33
post #26

Earlier quoted context omitted.

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?

Re: Fast cryptographically safe GUID generator for Go

#34
post #2

Much faster (~10x) than standard github.com/google/uuid package I'm interested in feedback from the HN community.

what real-world problem, if any, does 10x faster UUID generation solve? from your readme, `guid.New()` is 6~10 ns, so presumably the standard UUID package takes 60-100 ns? say I generate a UUID, and then use that UUID when inserting a row into my database, let's say committing that transaction takes 1 msec (1 million ns) if I get a speedup of 90 ns from using a faster UUID package, will that even be noticeable in my…

Amazon AWS S3 web servers process millions of requests per second, and each response generates a random Request-Id. It’s not exactly 16 bytes, but this is a very realistic scenario where guids are used in hot path. If you are writing a cute-kitten blog, might as well use Python instead..

Re: Fast cryptographically safe GUID generator for Go

#35

Advertising any UUID/GUID generator as cryptographically secure, or relying on it to be so, is a mistake, in my opinion. You use a UUID when you need a universally unique ID whose guessability properties are not a critical security requirement. While the V4 UUID spec (which this package does not implement, but most users might assume it does) states that a UUID implementation SHOULD be cryptographically secure [1], i…

The vast majority of Golang developers would benefit from using Guid library instead of UUID library. It’s substantially faster in all cases, more secure (by 2^6) and has more functionality. For random token-as-string generation Golang developers should be using https://github.com/sdrapkin/randstring instead of crypto/rand.Text (faster and more flexible).

The vast majority of Golang developers are neither hobbled by the lack of gigabyte throughput for random identifier generation nor are they on the verge of becoming victims to attacks on identifiers with "only" 2^122 random bits.

Re: Fast cryptographically safe GUID generator for Go

#36
post #17

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/…

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

Re: Fast cryptographically safe GUID generator for Go

#37
post #35

Earlier quoted context omitted.

The vast majority of Golang developers would benefit from using Guid library instead of UUID library. It’s substantially faster in all cases, more secure (by 2^6) and has more functionality. For random token-as-string generation Golang developers should be using https://github.com/sdrapkin/randstring instead of crypto/rand.Text (faster and more flexible).

The vast majority of Golang developers are neither hobbled by the lack of gigabyte throughput for random identifier generation nor are they on the verge of becoming victims to attacks on identifiers with "only" 2^122 random bits.

Agreed. So at worst they (Golang developers) should be indifferent, and at best they should opt for the faster choice. With serverless code billing by the second, faster choices are directly correlated to lower costs.

Re: Fast cryptographically safe GUID generator for Go

#38
post #35

Earlier quoted context omitted.

The vast majority of Golang developers are neither hobbled by the lack of gigabyte throughput for random identifier generation nor are they on the verge of becoming victims to attacks on identifiers with "only" 2^122 random bits.

Agreed. So at worst they (Golang developers) should be indifferent, and at best they should opt for the faster choice. With serverless code billing by the second, faster choices are directly correlated to lower costs.

> With serverless code billing by the second, faster choices are directly correlated to lower costs.

The kind of Go developers who think about these optimizations don't use overpriced, inefficient serverless services.

Re: Fast cryptographically safe GUID generator for Go

#40
post #26

Earlier quoted context omitted.

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.

Post reply on HN