[openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

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.dale at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170822/9d87a02b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4223 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170822/9d87a02b/attachment-0001.bin>