http://en.wikipedia.org/wiki/Globally_unique_identifier
Some flawed GUID-generating implementations rely on
pseudo-random number generators that use random number seed
sources that turn out to be predictable. Standard Valid GUIDs
are not chosen at random; they are chosen by standardized
algorithms. (See, e.g. RFC 4122.) These algorithms result in
GUIDs that are more reliably unique than ones chosen using
even a hypothetically perfect random number generator, and far
more reliably unique than numbers chosen by pseudorandom
number generators.
Wat?
V1 GUIDs which contain a MAC address and time can be
identified by the digit "1" in the first position of the third
group of digits, for example
{2F1E4FC0-81FD-11DA-9156-00036A0F876A}.
What could possibly go wrong?
V4 GUIDs use the later algorithm, which is a pseudo-random
number. These have a "4" in the same position, for example
{38A52BE4-9352-453E-AF97-5C3B448652F0}. More specifically, the
'data3' bit pattern would be 0001xxxxxxxxxxxx in the first
case, and 0100xxxxxxxxxxxx in the second. Cryptanalysis of the
WinAPI GUID generator shows that, since the sequence of V4
GUIDs is pseudo-random, given full knowledge of the internal
state, it is possible to predict previous and subsequent
values.
There should be a name for direct exposure of PRNG output, it's as
much a risk as adversary-controlled PRNG input.
GUIDs are commonly used as the primary key of database tables,
and with that, often the table has a clustered index on that
attribute. This presents a performance issue when inserting
records because a fully random GUID means the record may need
to be inserted anywhere within the table rather than merely
appended near the end of it.
Or... you could just use a row number (autoincrement, like MySQL), or
file offset (for direct access to row, like Oracle).
http://en.wikipedia.org/wiki/UUID
The variant indicates the layout of the UUID. The UUID
specification covers one particular variant. Other variants
are reserved or exist for backward compatibility reasons
(e.g., for values assigned before the UUID specification was
produced). An example of a UUID that is a different variant is
the nil UUID, which is a UUID that has all 128 bits set to
zero.
Hmmm. Only one type is random.
Conceptually, the original (version 1) generation scheme for
UUIDs was to concatenate the UUID version with the MAC address
of the computer that is generating the UUID, and with the
number of 100-nanosecond intervals since the adoption of the
Gregorian calendar in the West. This scheme has been criticized
in that it is not sufficiently "opaque"; it reveals both the
identity of the computer that generated the UUID and the time
at which it did so.
Nice privacy risk.
Version 3 UUIDs use a scheme deriving a UUID via MD5 from a URL,
a fully qualified domain name, an object identifier, a
distinguished name (DN as used in Lightweight Directory Access
Protocol), or on names in unspecified namespaces.
Nice rainbow table inversion risk in type 3 and 5 (SHA-1).
Someone could do a really neat paper on these and "random" URLs
and session IDs.
--
http://www.subspacefield.org/~travis/
Remediating... LIKE A BOSS
pgpvA4FvB1xd9.pgp
Description: PGP signature
_______________________________________________ RNG mailing list [email protected] http://lists.bitrot.info/mailman/listinfo/rng
