Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need a GUID. Really just any number that is likely to be unique. However I prefer not to leak time and other things as a GUID may leak. What should i use as a cryptographic replacement? I was thinking maybe i could use PBKDF2 using a GUID + salt/pepper but maybe thats overkill or not what i want?

share|improve this question
Possibly a conventional V4 guid is enough, or you should pull a random number out of a crypto PRNG. But without any details I can't tell you how big the number should be. 16 bytes might be enough, but it might be possible that you need 32. Please give a bit more information on what you use it for, and what security guarantees you need. – CodesInChaos Aug 9 '12 at 21:54
@CodesInChaos: I'm not sure exactly how much i need. A GUID may be allowed. What I do require is not knowing the origins of the machine that created the number. Time may be ok but i prefer not to have it. Maybe a PRNG is fine but how do i seed it? time ^ random_seed.Take(16) – acidzombie24 Aug 9 '12 at 22:05
Does the GUID have to be reproducible wrt a given resource(it wouldn't really be a GUID anymore but just making sure), if so, you kind of need to use the data in some form of hashing scheme. Otherwise a good PRNG is just what you need (e.g. OS-provided or a carefully implemented entropy accumulator). A proper CSPRNG does not need to be explicitly provided with a seed. – Thomas Aug 9 '12 at 22:10
You don't need to seen the PRNG. Pretty much any platform has a built in crypto PRNG that gets seeded by the OS. – CodesInChaos Aug 10 '12 at 7:01

I don't think you can do any better than the best random number you can generate.

share|improve this answer

It sounds like you want a "version 4 UUID", as generated by the Python function uuid.uuid4().

As defined in RFC 4122, version 4 UUIDs have 6 fixed bits (that indicate this is a "version 4 UUID") and 122 randomly generated bits.

(For your application, it may be simpler and therefore better to grab a full 128 random bits, and use them directly, as David Schwartz suggested).

Version 4 UUIDs are generally internally stored as a raw array of 128 bits, and typically displayed in a format something like:


where x is any (randomly chosen) hexadecimal digit and y is (randomly chosen from) one of 8, 9, a, or b.

Since the 6 fixed bits are the same for every UUID (no matter what machine created them, or what time it was created), and the remaining 122 bits are randomly generated, there is no information in a version 4 UUID that can identify what machine created it or when it was created.

The "randomly chosen" values are preferably from a cryptographically secure pseudorandom number generator, such as /dev/random, a hardware random number generator, or etc.

These "randomly chosen" values are preferably not from a "insecure" source of random numbers, such as the Python function random(), the Basic function rand(), the C stdlib function rand(), or etc.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.