Use Case
The google/uuid package currently utilizes Go's standard library crypto/md5 and crypto/sha1 within hash.go to generate name-based UUIDv3 and UUIDv5 identifiers. While these use cases are strictly deterministic and non-cryptographic (used primarily for generating unique, reproducible IDs from names and namespaces), maintaining hardcoded reliance on legacy hashing algorithms introduces technical debt, compliance friction, and operational risks as modern enterprise and cloud-native runtime environments evolve.
Purposes
Deterministic Identity Generation: Used in NewMD5 (UUIDv3) and NewSHA1 (UUIDv5) to derive standard 128-bit identifiers from a specific namespace and string/binary data context.
Compliance & Policy Verification: Ensures that third-party applications embedding this library can pass strict enterprise baseline checks, static analysis (SAST), and regulatory runtime policies without encountering blocking alerts regarding insecure primitives.
Motivation
-
Eliminating Weak Cryptographic Primitives: MD5 and SHA-1 have long been proven vulnerable to collision attacks. Even though UUID mapping is categorized as an identity tracking task rather than a security boundary, exporting and exposing functions anchored to weak hashes allows modern security scanners to flag the library as a risk.
-
Securing Hardened Runtime Environments: Modern secure-by-default runtime environments (such as Go binaries compiled under strict FIPS-140 compliance or BoringCrypto configurations) often explicitly block or panic upon instantiating crypto/md5 and crypto/sha1. Relying on hardcoded invocations of these packages risks introducing runtime failures in highly secure infrastructures.
-
Modernizing Specification Alignment: With the formal release of RFC 9562 (which supersedes RFC 4122), there is a standardized pathway for custom/experimental layouts via UUIDv8. Introducing support for modern hashing primitives like SHA-256 aligns the ecosystem with updated industry standards and eliminates structural technical debt.
Expected behavior
When configuring or utilizing name-based UUID generation, developers should be able to utilize strong, modern cryptographic hashing primitives (such as SHA-256) out of the box (e.g., via a standard UUIDv8 implementation or an upgraded deterministic generator) to comply with corporate security baselines.
Furthermore, security-conscious environments should have a compile-time or architecture-level pathway (such as build tags or modular split) to completely avoid or tree-shake the instantiation of legacy, cryptographically broken algorithms like MD5/SHA-1 if they are not actively invoked by the parent application.
Use Case
The google/uuid package currently utilizes Go's standard library crypto/md5 and crypto/sha1 within hash.go to generate name-based UUIDv3 and UUIDv5 identifiers. While these use cases are strictly deterministic and non-cryptographic (used primarily for generating unique, reproducible IDs from names and namespaces), maintaining hardcoded reliance on legacy hashing algorithms introduces technical debt, compliance friction, and operational risks as modern enterprise and cloud-native runtime environments evolve.
Purposes
Deterministic Identity Generation: Used in NewMD5 (UUIDv3) and NewSHA1 (UUIDv5) to derive standard 128-bit identifiers from a specific namespace and string/binary data context.
Compliance & Policy Verification: Ensures that third-party applications embedding this library can pass strict enterprise baseline checks, static analysis (SAST), and regulatory runtime policies without encountering blocking alerts regarding insecure primitives.
Motivation
Eliminating Weak Cryptographic Primitives: MD5 and SHA-1 have long been proven vulnerable to collision attacks. Even though UUID mapping is categorized as an identity tracking task rather than a security boundary, exporting and exposing functions anchored to weak hashes allows modern security scanners to flag the library as a risk.
Securing Hardened Runtime Environments: Modern secure-by-default runtime environments (such as Go binaries compiled under strict FIPS-140 compliance or BoringCrypto configurations) often explicitly block or panic upon instantiating crypto/md5 and crypto/sha1. Relying on hardcoded invocations of these packages risks introducing runtime failures in highly secure infrastructures.
Modernizing Specification Alignment: With the formal release of RFC 9562 (which supersedes RFC 4122), there is a standardized pathway for custom/experimental layouts via UUIDv8. Introducing support for modern hashing primitives like SHA-256 aligns the ecosystem with updated industry standards and eliminates structural technical debt.
Expected behavior
When configuring or utilizing name-based UUID generation, developers should be able to utilize strong, modern cryptographic hashing primitives (such as SHA-256) out of the box (e.g., via a standard UUIDv8 implementation or an upgraded deterministic generator) to comply with corporate security baselines.
Furthermore, security-conscious environments should have a compile-time or architecture-level pathway (such as build tags or modular split) to completely avoid or tree-shake the instantiation of legacy, cryptographically broken algorithms like MD5/SHA-1 if they are not actively invoked by the parent application.