crypto: upcoming Go 1.26 changes to random number sources are problematic for hardware-generated randomness

[sgmiller]

In Hashicorp Vault, we have customers that demand key generation proceed from hardware generated random number generators in PKCS#11 HSM devices. We had satisfied this by allowing them to choose this mode, and we'd supply the resultant entropy to the rand io.Reader on the various GenerateKey etc functions.

The upcoming Go 1.26 changes remove that possibility without the env var override that promises to be temporary. Our only alternative would be to fork the key generation routines to restore configurable entropy sources.

The upcoming release provides a way to supply randomness during testing, but that is frankly not the only use case for those parameters. For example, we also use a seeded DRBG during RSA prime generation for efficiency when using HSM sources as they have a limited entropy generation rate which can cause prime generation to take minutes.

[mknyszek]

CC @golang/security

[FiloSottile]

What key types specifically? Only RSA?

[sgmiller]

The feature is (awkwardly) called Entropy Augmentation (it's really direct entropy sourcing). A non-exhaustive list:

• ECDSA key generation for intra-cluster TLS.
• Ditto the above for Raft concensus TLS connections.
• Private key generation in our PKI CA, so RSA, ECDSA, and Ed25519
• Barrier encryption keys using AES-GCM (unaffected by this change I believe)

and then as mentioned, RSA key generation where we use a DRBG for prime selection seeded via the HSM. In that case we pass the DRBG's reader to GeneratePrimes.

[sgmiller]

For what it's worth, I appreciate what I assume is the desire for preventing people from accidentally using weak random sources. But in our case we're using it to plumb in strong sources. And I believe there are regulatory/audit driven requirements for many of our customers to have this.

[sgmiller]

Perhaps a compromise would be able to override this programmatically, ignoring the parameter by default but being able to opt in at runtime rather than via env var. That would also allow us not to opt in if our HSM entropy feature isn't enabled, for added safety.