sdrapkin

.NET: Avoid using Guid.CreateVersion7

TL;DR: Guid.CreateVersion7 in .NET 9+ claims RFC 9562 compliance but violates its big-endian requirement for binary storage. This causes the same database index fragmentation that v7 UUIDs were designed to prevent. Testing with 100K PostgreSQL inserts shows rampant fragmentation (35% larger indexes) versus properly-implemented sequential GUIDs.

Guid.CreateVersion7 method was introduced in .NET 9 and is now included for the first time in a long-term-supported .NET 10. Microsoft docs for Guid.CreateVersion7 state “Creates a new Guid according to RFC 9562, following the Version 7 format.” We will see about that.

RFC 9562

RFC 9562 defines a UUID as a 128-bit/16-byte long structure (which System.Guid is, so far so good). RFC 9562 requires UUIDv7

Refining Thread-Safe Randomness in Legacy .NET:
Pitfalls of Common `ThreadLocal<Random>` Wrappers

Generating random numbers is a common task, but System.Random in older .NET versions (including .NET Framework up to 4.8.x and .NET Core prior to 6.0) presents a well-known challenge: it's not thread-safe. Accessing a single Random instance from multiple threads concurrently can lead to corrupted internal state and output sequences that are far from random (often returning zeroes).

A popular solution often found online involves wrapping System.Random within a ThreadLocal<T> or using the [ThreadStatic] attribute. Articles like Andrew Lock's post and implementations such as ThreadSafeRandomizer showcase variations of this pattern. The core idea is to create a shared Random instance used only to seed thread-specific Random instances lazily.

Login.gov encryption is badly designed

Disclaimer: everything that follows is a personal opinion - not an assertion of fact.

Regulatory/Compliance flaws

NIST has created Federal Information Processing Standard (FIPS) 140-2: Security Requirements for Cryptographic Modules. FIPS requirements are mandatory for Federal Government agencies, as prescribed by FISMA law. FIPS-140-2 Annex D covers Approved Key Establishment Techniques. The only FIPS-approved password-based key derivation algorithm is PBKDF2 (NIST SP800-132). Login.gov uses scrypt, which is not FIPS-approved. The FIPS-approved key-derivation algorithms are mostly covered by NIST SP800-108. Login.gov uses several custom approaches for key derivation, none of which are FIPS-approved.

Summary:

RSA APIs in .NET - a crypto-trek rant

The stardate is 2017-06. In your .NET Enterprise mission to seek out biweekly paychecks you find yourself in need of RSA encryption. You check MSDN and do:

var rsa = RSA.Create();

Problem: the default RSA key size is 1024 (insecure).

You know about it because you've learned long ago that the only way to use .NET crypto APIs correctly is by reading implementation internals - you've seen 1024 hardcoded in the ctor. Defaults are forever, since "the needs of many outweigh the needs of the few" and all that. Fine, you'll set the key size explicitly. You double check MSDN again just to make sure that rsa.KeySize should do the job:

AssymmetricAlgorithm.KeySize: Gets or sets the size, in bits, of the key modulus used by the asymmetric algorithm.

	void Main() //LINQPad
	{
	var key1 = RandomNumberGenerator.GetBytes(128 + 1);
	var hash_of_key1 = SHA512.HashData(key1);
	var empty = Array.Empty<byte>();

	(Enumerable.SequenceEqual(key1, hash_of_key1)).Dump("key1 == hash_of_key1 ?");

	{
	var r1 = Convert.ToHexString(HMACSHA512.HashData(key: key1, source: empty));


	Warming up DB, DB client code and CLR
	====================================================================

	DataTable, using DbDataAdapter. Change tracking: True. Caching: False.
	--------------------------------------------------------------------------------------------
	[13:32:02] # of elements fetched: 31465. Fetch took: 214.79ms. Enumerating result took: 25.81ms.
	[13:32:03] # of elements fetched: 31465. Fetch took: 204.54ms. Enumerating result took: 24.42ms.
	[13:32:03] # of elements fetched: 31465. Fetch took: 195.04ms. Enumerating result took: 24.98ms.
	[13:32:03] # of elements fetched: 31465. Fetch took: 211.50ms. Enumerating result took: 24.06ms.