“Maybe use it for the boot-time ‘gather entropy from different sources,’ but clearly it should not be used at runtime.”
Good idea. Ask it during boot/insmod for some hardware-random bits to seed Linux’s usual software-only CSPRNG, then just use that.
And even that might not be a great idea. I wouldn’t be surprised if the fTPM RNG is subtly not-entirely-random, at some alphabet agency’s behest. I remember there being a controversy over rdrand for this reason…
The fix with any possible issues with rdrand is the same here. When entropy is gathered from many sources including hardware instructions, any nefarious plant in the chip is drowned out in a sea of noise.
Good idea. Ask it during boot/
insmodfor some hardware-random bits to seed Linux’s usual software-only CSPRNG, then just use that.And even that might not be a great idea. I wouldn’t be surprised if the fTPM RNG is subtly not-entirely-random, at some alphabet agency’s behest. I remember there being a controversy over
rdrandfor this reason…The fix with any possible issues with rdrand is the same here. When entropy is gathered from many sources including hardware instructions, any nefarious plant in the chip is drowned out in a sea of noise.
I’m no cryptographer, but that seems like an awfully dangerous assumption.
Well, it’s an fTPM, aka software, and AFAIK, no software can truly have a random RNG.
So it might be very good pseudo random at best.
It could be only mostly firmware, with a hardware RNG.
If not, and it uses a CSPRNG, then I don’t see much point in using it at all. Linux already has its own CSPRNG.