GUID Generator

GUID Generator

GUID and UUID describe the same 128-bit value. The difference is entirely presentational, and it comes from Microsoft's tooling conventions rather than from the standard.

The Microsoft Format

`` UUID: 9f1c8a2e-7b3d-4f6a-9c2e-1d8b4a6f3c07 GUID: {9F1C8A2E-7B3D-4F6A-9C2E-1D8B4A6F3C07} `

Uppercase hex, wrapped in braces. That is what the Windows registry stores, what Visual Studio project files contain, and what Guid.NewGuid().ToString("B") produces in .NET.

Format Specifiers in .NET

Specifier	Output
N	32 digits, no hyphens
D	32 digits with hyphens (the default)
B	Hyphens, wrapped in braces
P	Hyphens, wrapped in parentheses
X	Hexadecimal object notation

A system expecting B and receiving D will reject the value, and the error rarely says so clearly. When a GUID "isn't valid", the format specifier is the first thing to check.

The Byte-Order Trap

Microsoft's binary representation stores the first three groups little-endian while RFC 4122 specifies big-endian throughout. The same GUID therefore serialises to different bytes depending on which convention wrote it.

This surfaces when moving data between a .NET application and a system using RFC-standard UUIDs: the values look scrambled rather than merely different. .NET's Guid(byte[]) constructor and ToByteArray() both use the Microsoft order.

Where GUIDs Appear in Windows

• Registry keys for COM classes and interfaces (CLSID, IID)
• Project and solution files in Visual Studio
• MSI installer product and component codes
• Active Directory object identifiers
• Device instance paths in Device Manager

Changing a GUID in a project file after it has shipped breaks upgrade paths, which is why installer product codes are managed rather than regenerated.

Case Sensitivity

The hex is case-insensitive by the standard, but string comparison is not. Normalise to one case before comparing GUIDs as text — or better, compare them as GUID types rather than strings.

The Avalanche Effect

A one-character change produces a completely different digest — not a similar one. That property is what makes a hash useful as a fingerprint:

Input	MD5	CRC32
hello	5d41402abc4b2a76b9719d911017c592	3610a686
hello.	d94c10e437d18531e122ed0b45badd2a	0a39d4f1
Hello	8b1a9953c4611296a827abf8c47804d7	f7d18982

hello and Hello differ by one bit of one byte, and share no part of their output. RIPEMD-160 of hello is 108f07b8382412612c048d07d13f814118445acd, and of Hello is d44426aca8ae0a69cdbc4021c64fa5ad68ca32fe` — same story.

Digest Length and Collision Resistance

Algorithm	Output	Birthday bound	Status
CRC32	32 bits	~77,000 values	Checksum only
MD5	128 bits	2⁶⁴ in theory	Broken — collisions in seconds
SHA-1	160 bits	2⁸⁰ in theory	Broken — SHAttered, 2017
RIPEMD-160	160 bits	2⁸⁰	No practical attack
SHA-256	256 bits	2¹²⁸	Current standard
SHA-512	512 bits	2²⁵⁶	Standard, faster on 64-bit

The birthday bound is where a 50% chance of *some* collision appears among random inputs. MD5 and SHA-1 fall far short of theirs because both have practical collision attacks — you can construct two different files with the same digest, which is precisely what a signature must prevent.

Never Hash a Password With These

A general-purpose hash is designed to be fast, which is exactly wrong for passwords: speed helps the attacker. Use a deliberately slow KDF — bcrypt, scrypt or Argon2id — with a per-password salt. A GPU tries billions of SHA-256 guesses a second and a few thousand bcrypt guesses a second, and that gap is the entire defence.