sdrapkin

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.