UUID v1 vs v4 vs v5: Privacy & Collisions

1. Problem: UUID versions have different inputs, ordering, and privacy properties

RFC 9562 defines v1 using a 60-bit Gregorian timestamp, clock sequence, and 48-bit node field. That node can derive from an IEEE 802 MAC address or be randomly generated as the specification permits. v4 fills 122 non-version/variant bits from a random or pseudorandom source. v5 deterministically maps a namespace and name through SHA-1.

2. Minimal reproduction: UUID version structural comparison

This comparison illustrates string layout and determinism differences across UUID v1, v4, and v5:

/* 1. UUID v1: timestamp, clock sequence, and node field */
// "6c84fb90-12c4-11ee-be56-0242ac120002"
// Version nibble is 1; the node may come from a MAC or a compliant random node ID

/* 2. UUID v4: 122-bit Cryptographic Pseudo-Randomness (Most common) */
// "f47ac10b-58cc-4372-a567-0e02b2c3d479"
// Version nibble is 4; variant nibble is 8, 9, a, or b

/* 3. UUID v5: Namespace + Name SHA-1 Deterministic Hash */
// Passing "user_123" under the same Namespace always yields an identical UUID v5!

3. Root cause: node privacy, the birthday bound, and deterministic mapping

1. v1 privacy depends on the node source: a real MAC can expose vendor clues and generation time, while a compliant random node ID reduces that risk. 2. v4 collisions are probabilistic: the 122-bit space reaches birthday-bound scale near 2^{61} generations, but probability is never zero; keep a unique constraint and retry path. 3. v5 is deterministic: equal namespace/name inputs yield equal output, making it useful for stable mapping but unsuitable as an unguessable token.

4. Recommendation: choose by semantics and retain database constraints

1. Random identifiers without ordering: generate v4 from a cryptographically secure implementation. 2. Stable names within a namespace: use v5 and fix the name's encoding and normalization. 3. Time ordering and index locality: evaluate RFC 9562 v7, including timestamp exposure, same-millisecond monotonicity, and database behavior. 4. No UUID version automatically becomes an authentication token; retain unique constraints for identifiers.

5. Complete code: Web Crypto API deterministic UUID v5 generator

This TypeScript snippet demonstrates generating RFC 4122 compliant deterministic UUID v5 strings from namespaces and names using Web Crypto APIs.

async function generateUUIDv5(name: string, namespaceHex: string): Promise<string> {
  const cleanNs = namespaceHex.replace(/-/g, "");
  const nsBytes = new Uint8Array(16);
  for (let i = 0; i < 16; i++) {
    nsBytes[i] = parseInt(cleanNs.substr(i * 2, 2), 16);
  }

  const encoder = new TextEncoder();
  const nameBytes = encoder.encode(name);
  const data = new Uint8Array(nsBytes.length + nameBytes.length);
  data.set(nsBytes, 0);
  data.set(nameBytes, nsBytes.length);

  const hashBuffer = await crypto.subtle.digest("SHA-1", data);
  const hashBytes = new Uint8Array(hashBuffer);

  hashBytes[6] = (hashBytes[6] & 0x0f) | 0x50;
  hashBytes[8] = (hashBytes[8] & 0x3f) | 0x80;

  const hex = Array.from(hashBytes.subarray(0, 16))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");

  return [
    hex.substring(0, 8),
    hex.substring(8, 12),
    hex.substring(12, 16),
    hex.substring(16, 20),
    hex.substring(20, 32),
  ].join("-");
}

generateUUIDv5("user_1001", "6ba7b810-9dad-11d1-80b4-00c04fd430c8").then(console.log);

6. Incorrect approaches

Treating UUID v4 as an encryption secret (UUIDs are unique identifiers, not symmetric tokens). Assuming UUID v4 will collide in small-scale systems. Confusing v4 random generation with v5 idempotent lookup.

7. Boundaries: random-source quality and uniqueness handling

Math.random() is not cryptographically unpredictable, but its exact state space and collision behavior are implementation-dependent; it does not universally degrade to only a few thousand values. Generate v4 through crypto.randomUUID(), crypto.getRandomValues(), or a mature platform library, and still enforce uniqueness in storage.

8. Verification

Validate the common RFC 9562 text form with /^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i, then assert version and variant bits separately. A large no-duplicate sample catches obvious defects but cannot prove future uniqueness; inspect the random API, v5 test vectors, and database conflict path too.

9. FAQ

Can UUID v4 collide? The probability is extremely low with a sound random source but not zero, so a database unique constraint still matters.

Is v5 safe because it uses SHA-1? v5 is for deterministic naming, not unguessability or adversarial collision resistance; use an appropriate security construction at trust boundaries.

Does v7 replace auto-increment keys? Not universally. Its millisecond-ordered layout and random/monotonic fields can improve distributed generation and index locality, but storage width, page behavior, timestamp exposure, and ecosystem support require measurement.

10. Summary

Use v4 for random identifiers, v5 for stable name mapping, and consider v7 for time-ordered distributed IDs. Whether v1 exposes a MAC depends on its node-field implementation. Every choice still needs a unique constraint, and authentication tokens should be designed separately from business IDs.