> The adversary has the ability to put backdoors in your hardware so you can't trust it to give you truly random bits at all.
This makes zero sense. You trust your processor/chipset/mobo enough to do your bidding and not leak the sensitive plaintext data your app is processing.
But you don’t trust that hardware enough to give you entropy via RDRAND?
If your adversary is someone who can undetectably compromise your hardware you’ve already lost.
> You trust your processor/chipset/mobo enough to do your bidding and not leak the sensitive plaintext data your app is processing.
But you don’t trust that hardware enough to give you entropy via RDRAND?
Yes, because hardware that "leaks" app data would have to do it in ways that are easily detectable (for example, if an instruction to write a certain byte to one memory location also wrote it to some other location, or to an I/O port or a device driver). Whereas a compromised RDRAND can be undetectable--the bits it yields look random and pass all the tests I can give them for randomness, but are still predictable by the attacker.
I think your threat modeling needs some re-prioritization.
The universe of potentially undetectable hardware compromises is a much larger threat than a potential compromise of an RNG which is certain to be under constant scrutiny by security researchers.
You assume the existence of an attacker who is able and willing to compromise RDRAND but unable ore unwilling to implement one of a million other compromises at the same time. This seems unlikely.
This makes zero sense. You trust your processor/chipset/mobo enough to do your bidding and not leak the sensitive plaintext data your app is processing.
But you don’t trust that hardware enough to give you entropy via RDRAND?
If your adversary is someone who can undetectably compromise your hardware you’ve already lost.