1

Suppose we have an existing set of UUIDs (say, millions, though it doesn't matter) that may have been generated by different clients, so that we don't know the algorithm that generated any UUID. But we can assume that they are popular implementations.

Are there a set of 8 or more digits (not necessarily contiguous, though ideally yes) that are less or more likely to collide?

For example, I've seen the uuid() function in MySQL, when used twice in the same statement, generate 2 UUIDs exactly the same except the 5th through 8th digits:

0dec7a69-ded8-11e8-813e-42010a80044f
0decc891-ded8-11e8-813e-42010a80044f
    ^^^^

What is the answer generally?

The application is to expose a more compact ID for customers to copy and paste or communicate over phone. Unfortunately we're bound to using UUIDs in the backend, and understandably reluctant to creating mappings between long and short versions of IDs, but we can live with using a truncated UUID that occasionally collides and returns more than 1 result.

Andrew Cheong
  • 29,362
  • 15
  • 90
  • 145
  • UUIDs are implemented in a wide variety of algorithms. Some Use MAC (or similar) addresses for part and then part is based on timestamp and some bits are random. Others, the whole UUID is pseudo-random. In short: can you narrow down your question: What is the actual UUID generator being used? – sofend Nov 20 '18 at 22:22
  • With your two there being so close in value during the same query, it’s probably a time based UUID (v1 I think?). However, I’m not sure which, if any, parts are less likely to differ, I’m sure it wouldn’t matter if the user is copy/pasting anyway. I can see the annoyance in having to read out one over the phone all the time, though so maybe another approach is needed. – achAmháin Nov 20 '18 at 22:23
  • @sofend - I see. Well, that's why I was asking. I thought there might be a portion that's _more_ random regardless of the generator (because UUIDs were spec'ed a certain way, for example, regardless the generator). I _can_ narrow down the list of generators to Java (mulitple versions though) and Google's protobuf libraries. – Andrew Cheong Nov 20 '18 at 22:24
  • @achAmháin - Yup, and I know most of the generators and versions in use. My question is precisely what to do in the mixed case. – Andrew Cheong Nov 20 '18 at 22:25
  • The "right" answer in my opinion is to create a second, short identifier and either add it to the record, or if that schema is set in stone, create a trivial lookup table or service. Tell the user their short ID. Integrate lookup by short ID into the help desk tools, etc. ING Direct used to do this. Their transaction IDs had values like "27" or "15" or similar. I think I only once saw a 3-digit tx ID. Of course those were scoped to individual accounts thus keeping the IDs short, but presumably the user knows their name and other characteristics and so their account ID can be retrieved. – sofend Nov 20 '18 at 22:30
  • @sofend - Ah, yeah, I definitely agree with all the things you mentioned. But yes, the schema is set in stone, and basically the tech leads have already decisively ruled out lookup tables, so Design / Product versus Tech are at a standstill. I'm trying to come up with a middleground. Not having to do lookups or pass both long and short form IDs to the UI (by making the ID computable from the longform) would be a big sell. – Andrew Cheong Nov 20 '18 at 22:35
  • I just want to mention that a UUID is actually a 128-bit value, not text. So asking about digits is asking about the string of base-16 hexadecimal digits used canonically to represent those 128-bits for humans to read. Databases such as Postgres which natively store UUID values are **storing the bits, not the hex digits**. – Basil Bourque Nov 24 '18 at 20:27

2 Answers2

3

Suggestion: first 8 digits

1c59f6a6-21e6-481d-80ee-af3c54ac400a
^^^^^^^^

All generator implementations are required to use the same algorithms for a given version, so worry about the latter rather than the former.

UUID version 1 & version 2 are generally arranged from most to least entropy for a given source. So, the first 8 digits are probably the least likely to collide.

UUID version 4 and version 3 & 5 are designed to have uniform entropy, aside from the reserved digits for version and variant. So the first 8 digits are as good as any others.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
StephenS
  • 1,813
  • 13
  • 19
2

There is one method that will work, no matter the caveats of the UUID specification. Since a UUID is in itself intended to be globally unique, a secure hash made out of it using a proper algorithm with at least the same bit size will have the same properties. Except that the secure hash will have entropy through the hash value instead of specific locations.

As an example, you could do:

MessageDigest digest = MessageDigest.getInstance("SHA-256");
byte[] hash = digest.digest(uuid.toString().getBytes(StandardCharsets.UTF_8));

And then you take as many bits out of the hash as you need and convert them back to a String.

This is a one-way function though; to map it back to the UUID in a fast an efficient manner, you need to keep a mapping table. (You can of course check if a UUID matches the shorter code by performing the one-way hash on the UUID again)

However, if you were to take a non-contiguous portion out of the UUID, you would have the same issue.

Erwin Bolwidt
  • 30,799
  • 15
  • 56
  • 79
  • Interesting idea. Wikipedia has a [list of hash functions](https://en.wikipedia.org/wiki/List_of_hash_functions). Java offers the [`Checksum`](https://docs.oracle.com/javase/10/docs/api/java/util/zip/Checksum.html) interface with 2 or 3 implementations. The [Adler32 is not appropriate](https://en.wikipedia.org/wiki/Adler-32#Weakness) for a small input such as a UUID. But perhaps the 32-bits produced by the `CRC32` or `CRC32C` classes might be appropriate. – Basil Bourque Nov 24 '18 at 20:56