[Cryptography] [cryptography] Random number generation influenced, HW RNG

Owen Shepherd owen.shepherd at e43.eu
Mon Sep 9 10:06:03 EDT 2013


> -----Original Message-----
> From: cryptography-bounces+owen.shepherd=e43.eu at metzdowd.com
> [mailto:cryptography-bounces+owen.shepherd=e43.eu at metzdowd.com]
> On Behalf Of David Johnston
> Sent: 09 September 2013 05:41
> To: cryptography at metzdowd.com
> Subject: Re: [Cryptography] [cryptography] Random number generation
> influenced, HW RNG
> 
> #1 So that that state remains secret from things trying to discern that
state
> for purposes of predicting past or future outputs of the DRBG.
> 
> #2 So that one thread cannot undermine a second thread by putting the
> DRNG into a broken mode. There is only one DRNG, not one per core or one
> per thread. Having one DRNG per thread would be one of the many
> preconditions necessary before this could be contemplated.
> 
> #3 Any method of access is going have to be documented and supported and
> maintained as a constant interface across many generations of chip. We
don't
> throw that sort of thing into the PC architecture without a good reason.
> 
>   #4 Obviously there are debug modes to access raw entropy source output.
> The privilege required to access those modes is the same debug access
> necessary to undermine the security of the system. This only happens in
very
> controlled circumstances.

There are lots of aspects of IA-32/AMD64 which aren't consistent across
generations. The power management interface, for example, tends to get
somewhat infrequent backwards incompatible tweaks.

Fundamentally, I don't think anybody would have complained if you provided
some potentially non-stable method of /reading/ the RNG state; for example,
a bunch of MSRs (Hell, the potential instability is there in the name:
_Model_specific_, as much as a misnomer that is for the majority of stuff
dumped into an MSR) which could read the state wouldn't be out of the
question.

Plus, there it is: the required security protections. The only pieces of
software which can read MSRs are the kernel and SMM. If either of those is
compromised, well, you're boned anyway.

Some way of reading the raw RNG output, and establishing that things are
working as they should? That would give a lot of confidence

Also, you could have made rdrand set CF or similar if its state could be
predictable due to a recent read of the DRNG's state or similar.

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.21 (MingW32)

owGdVmtsFUUULigNVPABEX9o6BASHuH2UmgxUhEo1FLQUmyJDTakzt2dvTvt7sw6
M9vLQqI/JCBqVHzEGAMGI4I/MCUiCSgGCUHxQWLA1MYYqII2waAmJCoS4jmz996W
+M8mt72zO3POd77vO2f60qSbKsaOefu9fQemPju2MObLS7mK9ppvDy4hNfjTpnie
CxqQVqY1zTP7cFLVEtKsZNhAHJVERuYVjfykJidj4TA9VxaYyGqfRT5T7gOsvi7L
4mUhM5tcWXCzjgzxfFdIeWBkw/+LsAFDtAmynPk08EibR5poH3fJaukLbaTA1x1M
mAZSuwi+RIaFOabIgtr5daR2YUP9fNywTt5YwH8wdsS5HuZAkHbWQLpWjNq6gXQ5
NyzbqXBlSERs8+SZYIoangLhwgtiBoW5GdLSSdrXrMSn+Jkxn3RIYnxq0l/aUMOI
YsCN0EQzRzFDPGAaXnOR18SoBP4SI4nLtcOUGHUOA3pSkShWkdRME+mRSDGXOwbP
RFQbAq+92MSKERmbKDZ2k/EZaWpfvjJbhrWgDEsKBl8Uoy5xqBDSkFi4TIUcnlNE
KIVb2pBLILexySAkBmqCWqF8gEtJTsleJkgoXZYl60BYRjikF0Fik+DWDMEEuIqA
REciTIVrjIWP0kRZ0gJiQ5bSuVHvSEHGAUBh9mWxuJCKxIZQFi9HYTQRzEFPqwR2
e5gLONaQtXgedoJrogCYdUeYqSONIiFgFF+6GJ46GAQryUuE5NM+hvJAAFc6cQge
ZC4BcxAdR5FUxRXGQpENfPCJBoIgIegoDBLGlEcdYNhREqIj/lGesqI5Po+ypBPT
iFkG4wEBslD0AyRKi0dMVgDkYe0KQhUcNGBq9ECBQxmxgdx5CeUAf1qKcq2EzKgn
bbk+LmMNIhkrGYWPy3Jx3gqpsdQiBYoWCFSrZJRA/lg5JY/ZgCA40M/7eMDy6PAn
Yg7WHHUckGhWDMq1hatpWEqWbsJAI6rB2REv2v3MiRU3SUl2nWhQEM1WMppPo4gB
f1yQPqasJ1BmJYMAwDhcgWKoAaQA1JOq1pVrDmTaK1RHQJ79uqqxpm7BvMbWpnvr
ScHnjo8bQQsrJIfUIGVRwFHaZVMqYMIp1BVGKnpkRPOM7WG2kYL1YAFRXMtynqGs
ISugvjBRkEI8mKNOb4EqF4uCsRVBllwAfBQY7U2LaAaWKCahQZBkyKrUMdYbveDF
JCfdpNg21r0YJUh9yT2SyBiEkzBcYY0AADuWxjEa9KuoAcIw40hPzMNGBOPNsypg
f9r5dP+NlcFEgGHv44HWjnZNZrewIMjYI+UMUBNG5wGqmroCx4awuwQU1UC6W8Ey
QTfKwj3udGewmcIY1cCmCrkWAFqlfQEhEEM6E3pkySzaxJ5H3DiMsGY7rgSCmlPU
NZ0JdrxYX9kpbRlDInPW6CXTgSoahbbUrw1inSmhxvQNdk/Z/mXHAsPYlCMGsXaN
OJrdIpSeKaAPi4AAn4VjmaMq9X8v3AcssMOmo7U1S1Z5hHFMnmLD/rIDLoRswAte
RwXLOWg8C2LkpJ1Fx7pEUqCJLaADBYcFRiiqmlYAzY7Cph2esTmZNQLXfrqJmtKl
ZXFL1YvPqRURJoSP9C2FWmFfar4878M7JZCWS2giDzwHrYg4GgMtLc6iFtaoIXUB
iavsdIX2WNGM14XmIQ+oQu9yaNRUrPJUL16I1rFubEc1hcocbCXLaPk+XLNyVun0
SNTs9jH33FwxZmxF5bix+F9SRdWE20v/Ou0+PL7i/ZOTf95ywq/8dPquc+7J8eS2
2XOeOjv+m+P9H4fjxu+bPnB64mtXZz4UdN+yZ8+EaYsvH9/xxw8HZjbWnh4+++af
Xy3+5Vpbzc7HTq3Yf5Rt7x88NrRxOB545sUH5645P/HHt+oHn26a3H/qRM+lqfcN
DW9rca/c+vqVV/euv2tz8+r+i3d3fLA3f/3cjsyj7kdDnw0f2PTqw69UVcYv7Ny9
6uSZlw9OGxg+NHT5i8WP7CDLtv302+bjucd7sjOGf/9rad8RTx6tvtpZOfBG9a+r
71x/eP+FubP52U/OLNxy8cPTU7YOdn7+XfU/7/QPbv363BHxnDr6/CE+ZfK7xy7d
sfX4ovOZ609e+/v75Xurdw1VtfIL1f8C
=YDgw
-----END PGP MESSAGE-----



More information about the cryptography mailing list