Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fast cryptographically safe GUID generator for Go

github.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Fast cryptographically safe GUID generator for Go

#21

Post by sdrapkin »

imiric wrote: post #19
sdrapkin wrote: post #18

Earlier quoted context omitted.

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.

Re: Fast cryptographically safe GUID generator for Go

#22

Post by saclark11 »

sdrapkin wrote: post #13
deathanatos wrote: post #7

These aren't GUIDs[1]. If it isn't meant to follow the RFC, … just find a new word. (There are plenty of alternate schemes out there, too.) [1]: https://www.rfc-editor.org/rfc/rfc9562.html

IMHO "Guid" is just as well known (Wikipedia agrees: https://en.wikipedia.org/wiki/Universally_unique_identifier ), and "UUID" was already taken by Google.

> "UUID" was already taken by Google.

This shouldn't really matter as your import paths are obviously different. `github.com/google/uuid` and `github.com/sdrapkin/guid` can happily coexist. Any file/codebase importing both (which would ideally be avoided in the first place) can alias them.

> IMHO "Guid" is just as well known

I think the point the commenter was trying to make is that these do not adhere to the UUID spec. You don't specify which version, but judging by the docs and your comparison to `github.com/google/uuid`, I'd wager most folks looking at this library would assume they are supposed to be V4 UUIDs.

Re: Fast cryptographically safe GUID generator for Go

#23

Post by sdrapkin »

danbruc wrote: post #20
sdrapkin wrote: post #13

Earlier quoted context omitted.

IMHO "Guid" is just as well known (Wikipedia agrees: https://en.wikipedia.org/wiki/Universally_unique_identifier ), and "UUID" was already taken by Google.

I think the point is that this just generates 16 random bytes whereas UUIDs/GUIDs have structure, they at least have a variant fields indicating what kind of UUID/GUID it is. The closest thing to all random bytes would be variant 10xx, version 4 or 8.

You are correct - Guid very specifically and intentionally generates a structure of 16 random bytes. In decades of programming I've never needed a random 16-byte structure to have a "internal versioned structure". In very rare cases this is truly needed, bit-twiddling post-generation can cheaply fix it (but not the other way around). Which is why all these "versions" and "variants" in standard universally applicable libraries are a complete waste of entropy and cycles.

Re: Fast cryptographically safe GUID generator for Go

#24

Post by sdrapkin »

saclark11 wrote: post #22
sdrapkin wrote: post #13

Earlier quoted context omitted.

IMHO "Guid" is just as well known (Wikipedia agrees: https://en.wikipedia.org/wiki/Universally_unique_identifier ), and "UUID" was already taken by Google.

> "UUID" was already taken by Google. This shouldn't really matter as your import paths are obviously different. `github.com/google/uuid` and `github.com/sdrapkin/guid` can happily coexist. Any file/codebase importing both (which would ideally be avoided in the first place) can alias them. > IMHO "Guid" is just as well known I think the point the commenter was trying to make is that these do not adhere to the UUID sp…

> This shouldn't really matter as your import paths are obviously different.

I'm aware of that, of course. Guid is intentionally named differently from "uuid" (both as a package and as a type) to ensure there is no confusion between them in code. It is not the goal of Guid to mimic/inherit all uuid APIs. Guid is its own package, with a different API surface and roadmap (ie. I'll borrow what makes sense and do things differently when it makes sense).

Re: Fast cryptographically safe GUID generator for Go

#25

Post by danbruc »

sdrapkin wrote: post #23
danbruc wrote: post #20

Earlier quoted context omitted.

I think the point is that this just generates 16 random bytes whereas UUIDs/GUIDs have structure, they at least have a variant fields indicating what kind of UUID/GUID it is. The closest thing to all random bytes would be variant 10xx, version 4 or 8.

You are correct - Guid very specifically and intentionally generates a structure of 16 random bytes. In decades of programming I've never needed a random 16-byte structure to have a "internal versioned structure". In very rare cases this is truly needed, bit-twiddling post-generation can cheaply fix it (but not the other way around). Which is why all these "versions" and "variants" in standard universally applicable…

I do not think I have seen or noticed code that inspects UUID variants either but I could certainly imagine that such code is out there, for example to protect against accidental information leakage from UUID variants that are not purely random. With that in mind it seems a good idea to adhere to the standards if one uses an established name. Neither the few lost bits nor the effort to correctly indicate the variant sound like real issues to me.

Re: Fast cryptographically safe GUID generator for Go

#26

Post by shakna »

sdrapkin wrote: post #21
imiric wrote: post #19

Earlier quoted context omitted.

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.

Re: Fast cryptographically safe GUID generator for Go

#27

Post by saclark11 »

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], it also states that they MUST NOT be used as security capabilities [2]. This is b/c they are not intended as secure tokens, but many users mistakenly assume them to be suitable as such. Not to mention, V4 UUIDs only have 122 bits of entropy, not 128, since 6 bits are reserved for version and variant information, which many users don't realize.

So you can generate a UUID that is suitable as a secure token, but at that point don't call it a UUID. Just call it a secure token. And if you need a secure token, use something like Go's `Text()` function from `crypto/rand` [3].

The situation reminds me of how the Go team updated the `math/rand` and `math/rand/v2` packages to use a CSPRNG as a defensive measure [4], while still urging users to use `crypto/rand` in secure contexts.

[1]: https://www.rfc-editor.org/rfc/rfc9562.html#unguessability

[2]: https://www.rfc-editor.org/rfc/rfc9562.html#Security

[3]: https://pkg.go.dev/crypto/rand@go1.24.5#Text

[4]: https://go.dev/blog/chacha8rand

Re: Fast cryptographically safe GUID generator for Go

#28

Post by imiric »

sdrapkin wrote: post #21
imiric wrote: post #19

Earlier quoted context omitted.

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.

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.

Re: Fast cryptographically safe GUID generator for Go

#29

Post by evil-olive »

sdrapkin wrote: 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 benchmarks? it seems likely to be lost in the noise.

honestly, this seems like going on a 7-day road trip, and sprinting from your front door to your car because it'll get you there faster.

Re: Fast cryptographically safe GUID generator for Go

#30

Post by taeric »

danbruc wrote: post #25
sdrapkin wrote: post #23

Earlier quoted context omitted.

You are correct - Guid very specifically and intentionally generates a structure of 16 random bytes. In decades of programming I've never needed a random 16-byte structure to have a "internal versioned structure". In very rare cases this is truly needed, bit-twiddling post-generation can cheaply fix it (but not the other way around). Which is why all these "versions" and "variants" in standard universally applicable…

I do not think I have seen or noticed code that inspects UUID variants either but I could certainly imagine that such code is out there, for example to protect against accidental information leakage from UUID variants that are not purely random. With that in mind it seems a good idea to adhere to the standards if one uses an established name. Neither the few lost bits nor the effort to correctly indicate the variant…

I was on a team once that would add server information to ids. Between that and using the version that has a date on it, it made debugging things MUCH easier. Just plug in the id and tooling could easily determine which logs to look into for when it was generated. Obviously, you may still need to widen your search for many reasons. But it is hard for me to think this is on most people's threat model.
Post reply on HN