0

I'm very curious as to why the format is xxxxxxxx-xxxx-4xxx-zxxx-xxxxxxxxxxxx? Why is the 4 there, and why is z always either 8, 9, A, B? And also, why the different string lengths between the dashes? What is the rationale behind all of this, and does it have any implications for generating cryptographically secure strings?

EDIT: I made the assumption (wrongly), that UUID v4 is necessarily crytopgrahically secure. I was looking for the security related rationale for its format. But, yes, I can understand that very strictly speaking this is not a security question. Anyway, it is my understanding that UUIDs built with CSPRNGs can be cryptographically strong.

Improve this question
1
  • 4
    The 4 is the version number. This prevents different GUID/UUID algorithms being used in the same system from colliding. Some older UUID algorithms used the machine's mac address, then tried to ensure uniqueness for the rest of the fields. This would mean certain areas of the UUID space would be a mine field for a random algorithm.
    – Aron
    Aug 16, 2016 at 9:37

1 Answer 1

Reset to default
10

Variants and Versions:

A UUID has variants and versions.

The 4 in this case tells you, that it is the version 4. Other versions range from 1 to 5.

Those versions have variants 8, 9, A and B, therefore the z in your UUID tells you which variant it is.

The variant is used for telling which layout the UUID has. Variants are also important when it comes to backwards compatibility.

Lenght of the strings:

As to why the strings have different lengths, a UUID has a certain parts, that you can use to generate a UUID depending on various parameters:

UUID =  time-low "-" 
        time-mid "-" 
        time-high-and-version "-" 
        clock-seq-and-reserved | clock-seq-low "-" 
        node

time-low has 16 bits, time-mid has 8 bits, ... The lengths were historically constructed so that they fit into the following scheme:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          time_low                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       time_mid                |         time_hi_and_version   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         node (2-5)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So this should give you an idea, why the lengths of the strings are different.

UUIDs and security:

Usually UUIDs are not secure: https://littlemaninmyhead.wordpress.com/2015/11/22/cautionary-note-uuids-should-generally-not-be-used-for-authentication-tokens/ ... and see Michael Kjörling's comment for further examples and explanations.

UUIDs were not built to be cryptohraphically secure, so you should use something else made especially for that purpose.

The RFC for UUIDs even has a section, about security, warning users to misuse UUIDs for that:

  1. Security Considerations

Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.

See the RFC for the technical details: https://www.rfc-editor.org/rfc/rfc4122

Improve this answer
1

Not the answer you're looking for? Browse other questions tagged .