fcrand (fast crypto/rand) is a high-performance drop-in replacement for Go's crypto/rand.
Readit Newssdrapkin commented on Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster github.com/sdrapkin/fcran... · Posted by u/sdrapkin
sdrapkin commented on Fast cryptographically safe GUID generator for Go github.com/sdrapkin/guid... · Posted by u/sdrapkin
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.
sdrapkin commented on Fast cryptographically safe GUID generator for Go github.com/sdrapkin/guid... · Posted by u/sdrapkin
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.
sdrapkin commented on Fast cryptographically safe GUID generator for Go github.com/sdrapkin/guid... · Posted by u/sdrapkin
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.
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..
sdrapkin commented on Fast cryptographically safe GUID generator for Go github.com/sdrapkin/guid... · Posted by u/sdrapkin
sdrapkin commented on Fast cryptographically safe GUID generator for Go github.com/sdrapkin/guid... · Posted by u/sdrapkin
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.
sdrapkin commented on Fast cryptographically safe GUID generator for Go github.com/sdrapkin/guid... · Posted by u/sdrapkin
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
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).
sdrapkin commented on Fast cryptographically safe GUID generator for Go github.com/sdrapkin/guid... · Posted by u/sdrapkin
> "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.
> 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).
sdrapkin commented on Fast cryptographically safe GUID generator for Go github.com/sdrapkin/guid... · Posted by u/sdrapkin
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.