My offhand knee-jerk reaction would be that if you have a CPU compromised to 
that extent - the battle has been lost with no reason to continue.

Going into more details, I checked that post, and disagree with the author (and 
I'm in a good company, as Linus seems to hold the same opinion). According to 
the author (as I understood him), not only RDRAND must be compromised (i.e., 
produce bad output), but the CPU would have to switch to a "special" processing 
mode when RDRAND instruction is detected. And this malicious CPU would have to 
understand how RNG is implemented in Linux, Mac, Windows, FreeBSD (at what 
point it calls RDRAND and what instructions follow)... And it's betting on 
RDRAND being the last in the chain of RNG inputs (otherwise it would wipe out 
previous entropy, but would in turn be replaced by something good from the next 
source). Also, usually mixing = XOR, but some prefer arithmetic addition - so 
RDRAND would be crafted to replace any subsequent operation to copy. Plus, it 
would have to track a bunch of the following instructions because it's common 
but not certain that the RDRAND output is mixed in immediately (in the very 
next instruction)...

To summarize, I don't have enough tin-foil for a hat of that size.

But regardless, a good solution IMHO is to offer an interface to mix in (add to 
the pool) whatever data the user wants as an additional input (in terms of SP 
800-90A that defined "additional input" to mix during reseeding and 
generation). That data could be an output of RDRAND, of an external RNG 
(including hardware TRNG), or... It would be up to the user to pick the 
additional source that he trusts. Also, nobody forces the user to employ that 
interface at all (just like on a decent OS nobody now is forced to use 
RAND_add()) - but it would be there for those who need/want it. 

Regards,
Uri

Sent from my iPhone

> On Aug 21, 2017, at 20:06, Paul Dale <paul.d...@oracle.com> wrote:
> 
> Uri wrote:
>>>  It might also use things like RDRAND / RDSEED which we don't trust.
>> ...
>> From cryptography point of view, it cannot hurt, but may help a lot    
> 
> There is a scenario where it does hurt: 
> https://www.lvh.io/posts/2013/10/thoughts-on-rdrand-in-linux.html
> 
> This attack wouldn't be difficult to implement given all the out of order 
> execution and look ahead that CPUs do.   It requires a compromised RDRAND 
> instruction changing the behaviour of a subsequent XOR into a copy.  Not only 
> would it not be producing random bits but it would remove any randomness from 
> the bits you already have.
> 
> 
> Pauli
> -- 
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to