middleware/requestid: mention that the default UUID generator exposes the number of requests made to the server

[leonklingele]

No description provided.

[leonklingele]

For v3, I'd make the utils.UUIDv4 generator the default. Personally, I'd recommend anyone to go for the more privacy-preserving option. Leaking the number of requests to me is quite a no-go and should not be the default choice here.

What do you think?

[ReneWerner87]

@leonklingele you are talking about

fiber/utils/common.go

Line 54 in 6d798db

x := atomic.AddUint64(&uuidCounter, 1)

could something be changed in the way of creation that is comparably fast but does not reveal the number of requests made ?

whereby one does not really have the start, because this is random

[leonklingele]

We could start off with a crypto-random seed — a byte slice — and hash it once more per request using a fast and secure (i.e. pre-image resistant) hashing function such as SHA256. If performance is really crucial, we could even pre-generate the next couple of hashes so their calculation doesn’t block the request. I’ll do some benchmarks on this.

[leonklingele]

Here are some benchmarks: https://github.com/leonklingele/uuidbench#go-uuid-benchmark

It looks like switching to the construction mentioned above using Blake2s instead of SHA256 is a fast and secure alternative to UUIDv4.

[ReneWerner87]

Well, is there another way that just tries to solve this security problem without causing a doubling of time?
By incrementing other parts or adding randomly when increasing the counter part

We would only have to make sure that no collisions occur