How are keys handled?

[okay9109]

Hello,

When using FIPS version of Bouncy Castle dlls to read RSA private/public keys, I suppose it follows the FIPS guidelines to deal with those keys in-memory, such as encrypting and zeroizing them.

How about the regular Bouncy Castle library (non-FIPS)? Does it also apply this type of protection to RSA keys that are in memory?

[KonradSop]

I looked into this, since I was curious too. Short answer: the non-FIPS version of BouncyCastle does not protect private keys in memory. No encryption, no zeroization, no IDisposable.

Here's what I found in the source code.

Asymmetric keys are stored as plain BigInteger

RSA private keys (RsaPrivateCrtKeyParameters) keep all the sensitive values -- p, q, dP, dQ, qInv, the private exponent -- as BigInteger fields. BigInteger is a sealed class with a readonly uint[] for its internal data, so there's no way to zero it out in place. This is the same for EC, DH, and DSA private keys.

What surprised me is that newer algorithms like Ed25519, X25519, and ML-KEM store their private keys as byte[] arrays, which could be zeroed with Array.Clear(). But none of them do. None of the 14 private key parameter classes in the library implement IDisposable.

Some secrets do get cleaned up, though

The library does have cleanup in other places:

• TLS session secrets (AbstractTlsSecret) have a Destroy() method that calls Array.Clear() and nulls the reference. There's actually a TODO comment in the source that says // TODO Is there a way to ensure the data is really overwritten?, which tells you even the maintainers aren't fully confident this works given GC compaction.
• Post-quantum KEM secrets (SecretWithEncapsulationImpl) implement IDisposable and clear session key and ciphertext on disposal.
• Blake2b/2s/3 digests have ClearKey() for their symmetric keys.

So there's a split: byte-array-based secrets get some degree of cleanup, but BigInteger-based asymmetric keys get nothing.

Why this is hard to fix on .NET

The core issue is .NET's managed memory model. The GC can copy objects during heap compaction, so even if you zero a buffer, earlier copies might still be sitting somewhere in memory. BigInteger being immutable makes this even harder -- there's no API to mutate the internal data.

What you can do about it

If you control the code that loads keys, you can at least clear any intermediate byte[] buffers with CryptographicOperations.ZeroMemory() before passing them to the BC constructors. That won't help with the copies BC makes internally, but it reduces exposure on your side.

If your threat model actually requires proper key lifecycle management (zeroization, protected memory), the FIPS-certified edition (BC-FNA 1.0.2) is built for that, though it has a different API and isn't a drop-in replacement.

Source references

• AsymmetricKeyParameter
• RsaPrivateCrtKeyParameters
• Ed25519PrivateKeyParameters
• BigInteger (sealed, readonly magnitude)
• AbstractTlsSecret.Destroy()
• SecretWithEncapsulationImpl

[okay9109]

@KonradSop This answers my question, thank you very much for the detailed explanation!