Live data from Hacker News

Fast cryptographically safe GUID generator for Go

github.com

1–10 of 43 posts

Re: Fast cryptographically safe GUID generator for Go

#4
On an extremely quick review:

- This uses global state under the hood. Surprise! Is it thread safe? I’m not a Go expert, but it looks non-thread-safe.

- The copying code reminds me of old-school awful C buffer handling code. Maybe it’s right. Maybe it’s wrong. But it’s not obviously right.

- The actual meat is a cryptographic randomness cache. This is a subtle thing, and all the best practices are missing. Where’s the backtracking protection? What if the program forks? vDSO getrandom() knows how to do this correctly — something high-level should use it, not reimplement it incorrectly.

Re: Fast cryptographically safe GUID generator for Go

#5
post #2

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

Why is it so much faster than `uuid`?

It generates entropy 4kb-at-a-time (instead of on each call), and uses a cache-pool instead of single cache behind a lock (which is what standard uuid does in "RandPool=ON" mode).

Re: Fast cryptographically safe GUID generator for Go

#6
post #4

On an extremely quick review: - This uses global state under the hood. Surprise! Is it thread safe? I’m not a Go expert, but it looks non-thread-safe. - The copying code reminds me of old-school awful C buffer handling code. Maybe it’s right. Maybe it’s wrong. But it’s not obviously right. - The actual meat is a cryptographic randomness cache. This is a subtle thing, and all the best practices are missing. Where’s th…

Thanks for your feedback. If you are skilled in Golang, I suggest you review the code more thoroughly for a more accurate understanding (especially compared to what standard uuid does).

Re: Fast cryptographically safe GUID generator for Go

#9
post #5

Earlier quoted context omitted.

Why is it so much faster than `uuid`?

It generates entropy 4kb-at-a-time (instead of on each call), and uses a cache-pool instead of single cache behind a lock (which is what standard uuid does in "RandPool=ON" mode).

So this automatically makes it unsafe in case of VM snapshots.

The Linux kernel now has an optimization that makes it safe: https://lwn.net/Articles/983186/

Go should automatically benefit from this, if they use the vDSO getrandom().

Re: Fast cryptographically safe GUID generator for Go

#10
post #4

On an extremely quick review: - This uses global state under the hood. Surprise! Is it thread safe? I’m not a Go expert, but it looks non-thread-safe. - The copying code reminds me of old-school awful C buffer handling code. Maybe it’s right. Maybe it’s wrong. But it’s not obviously right. - The actual meat is a cryptographic randomness cache. This is a subtle thing, and all the best practices are missing. Where’s th…

Global use looks fine - it's a very-simply-used sync pool to do larger blocks of rand reads, which makes plenty of sense for performance.

Unsafe use also looks fine, values either don't escape the function (a type string->byte type cast for function signature reasons) or they do but they're new temporary data (the byte->string cast, which is fine because there's no risk of reusing or modifying the original bytes).

I'm going to intentionally not make any claims to "cryptographic security" or "is this a GUID" as I'm not super clear on the details there. The code looks pretty normal to me though, with the possible exception of the base64 encoding (why not base64.URLEncoding? https://pkg.go.dev/encoding/base64#pkg-variables).

Post reply on HN