Pitchforks for RDSEED

Posted Feb 9, 2024 12:18 UTC (Fri) by zx2c4 (subscriber, #82519)
In reply to: Pitchforks for RDSEED by spacefrogg
Parent article: Pitchforks for RDSEED

The issue isn't that it fails but that one trust domain can potentially force failures in another. If it would "eventually succeed", one could try again and again until success. But if a different domain can induce perpetual failure, then we've now got two problems. So solutions include making RDRAND keep generating stream output without fail, or imposing some sort of cross-domain fairness with regards to failures. The threads on LKML discuss this.

Pitchforks for RDSEED

Posted Feb 9, 2024 12:42 UTC (Fri) by spacefrogg (subscriber, #119608) [Link] (3 responses)

True, I was not arguing against that. It came across in the article that Dave Hansen suggested to consider failing TRNGs to signify broken hardware, which is not a proper way to look at the issue.

Cross-domain fairness seems to be hard to achieve when I think about it, especially because entropy is such a scarce resource. Access to the entropy source should be exclusive to the kernel(s). Applications should have to make due with derived PRNG values. But I am just thinking out loud...

Pitchforks for RDSEED

Posted Feb 9, 2024 12:59 UTC (Fri) by spacefrogg (subscriber, #119608) [Link] (2 responses)

Thinking about it further, entropy is like CPU time. Once consumed by a process, you cannot get it back (opposed to memory), but you have to let time pass. So, an entropy-access scheduler seems to be one solution. Processes would need to announce to the kernel that they want to be part of the list of entropy users and get a scheduled and limited amount of RDSEED calls. Obviously, this needs close monitoring of the systems entropy state, which might be hard to do and may end up to be as good as limiting calls to x/sec.

Pitchforks for RDSEED

Posted Feb 9, 2024 13:28 UTC (Fri) by zx2c4 (subscriber, #82519) [Link] (1 responses)

These are unprivileged CPU instructions. This isn't a kernel scheduler issue.

Pitchforks for RDSEED

Posted Feb 9, 2024 14:31 UTC (Fri) by spacefrogg (subscriber, #119608) [Link]

Then the CPUs are actually broken. You must guard your entropy state or its useless to you.

Daniel J. Bernstein has an excellent write-up about how you could potentially mis-use an entropy source to force your encryption scheme to leak your private key alongside your ciphertext while making it look perfectly fine. I just fail to find it right now. (It was concentrating on why encryption schemes should not mindlessly access entropy)

The argument is quite simple: You do know how the encryption scheme distributes bits. If you control the entropy bits and the encryption scheme, you can hide the private key in the entropy bits and make the ciphertext partially predictable, enough to recover the private key and thus the original message.