search

google / uuid

Go package for UUIDs based on RFC 4122 and DCE 1.1: Authentication and Security Services.
BSD 3-Clause "New" or "Revised" License
5.24k stars 363 forks source link

Is this package cryptographically secure? #77

Closed ghost closed 3 years ago

ghost commented 3 years ago

I am working on a legacy app that used UUID v4 as its authentication key. Is that secure? (Some implementations, like python3's are secure, meanwhile others aren't)

Moving the entire app to crytpo/rand would be way too much.

pborman commented 3 years ago

The generation of the UUID uses crypto/rand, but can be changed. I would trust the randomness of the UUID but if you want secrecy the package does not attempt to take extraordinary efforts to keep the UUIDs secret in its own memory space, there may be copies left on the heap or in freed memory. If 122 bits of randomness is sufficient then this is as good as reading it directly from crypto/rand (since that is basically what the v4 UUIDs are.). Otherwise, just use crypto/rand.Read directly.

ghost commented 3 years ago

The generation of the UUID uses crypto/rand, but can be changed. I would trust the randomness of the UUID but if you want secrecy the package does not attempt to take extraordinary efforts to keep the UUIDs secret in its own memory space, there may be copies left on the heap or in freed memory. If 122 bits of randomness is sufficient then this is as good as reading it directly from crypto/rand (since that is basically what the v4 UUIDs are.). Otherwise, just use crypto/rand.Read directly.

Okay, so just to clarify, can I use UUIDs as this app's authorization tokens? Thank you a lot.

pborman commented 3 years ago

I can't really answer that, it depends on your application. If you were guarding nuclear launch codes I would definitely say No! but for more mundane applications, if 122 bits is sufficient then I think it is as good as reading directly from crypt/rand.Read. Just realize there are 6 bits out of the 128 which are fixed to known values which is why you only get 122 bits of randomness. I guess it also depends on your encryption algorithm. There simply is no generic answer to the question.

ghost commented 3 years ago

I can't really answer that, it depends on your application. If you were guarding nuclear launch codes I would definitely say No! but for more mundane applications, if 122 bits is sufficient then I think it is as good as reading directly from crypt/rand.Read. Just realize there are 6 bits out of the 128 which are fixed to known values which is why you only get 122 bits of randomness. I guess it also depends on your encryption algorithm. There simply is no generic answer to the question.

Ok, great, thanks!