4 ms·

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 univers

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 https://www.rfc-editor.org/rfc/rfc9562.html#unguessability [2]: https://www.rfc-editor.org/rfc/rfc9562.html#Security https://www.rfc-editor.org/rfc/rfc9562.html#Security [3]: https://pkg.go.dev/crypto/rand@go1.24.5#Text https://pkg.go.dev/crypto/rand@go1.24.5#Text [4]: https://go.dev/blog/chacha8rand https://go.dev/blog/chacha8rand

sdrapkin 1y ago
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 https://github.com/sdrapkin/randstring instead of crypto/rand.Text (faster and more flexible).
- stouset 1y ago
  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.
  - sdrapkin 1y ago
    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.
    - lossolo 1y ago
      > 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.

sdrapkin 1y ago

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 https://github.com/sdrapkin/randstring instead of crypto/rand.Text (faster and more flexible).

stouset 1y ago
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.
- sdrapkin 1y ago
  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.
  - lossolo 1y ago
    > 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.