How a months-old AMD microcode bug destroyed my weekend [UPDATED]

[coderman]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 29, 2019 7:39 PM, jim bell <jdb10987 at yahoo.com> wrote: ...

> I think that any microprocessor which purports to be able to internally-generate "random numbers" should also be equipped with an input (possibly a single line) which is intended to be connected to an external source of random numbers, intended to be mixed with the internal random source, for example:
>
> http://www.fdk.com/cyber-e/pi_ic_rpg100.html
>    or
> https://www.idquantique.com/random-number-generation/products/quantis-qrng-chip/?gclid=CjwKCAjwxt_tBRAXEiwAENY8hU5d5R0aujGaQjDCHS6Ej_gwwLk8Sz9Z6XG71zec2o9HlcTyjHPaIhoC7HMQAvD_BwE
>    or
> https://ieeexplore.ieee.org/document/847868
>
> This should minimize the possibility that defects in one source can affect the randomness of the ultimately-used data stream,

anon from the wiki agrees with you :P
( https://trac.torproject.org/projects/tor/ticket/10402 :)

TL;DR:
some years back OpenSSL shipped with at the time recent versions likely to use RDRAND as sole source of entropy when generating keys.  Intel refuses to grant access to raw accumulators / registers - even RDSEED is masked by DBRG obfuscation before returning "RAW SEED ENTROPY" hahah...  seriously. Mix in it, but never trust as sole source...

c.f.: https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed

spooks love to fuck with RNGs; won't be the last time, either!

best regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 3275 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20191030/43247f48/attachment.txt>