Use RdSeed when available, and reduce RdRand load

[sipa]

This introduces support for autodetecting and using the RdSeed instruction on x86/x86_64 systems.

In addition:

• In SeedFast, only 64 bits of entropy are generated through RdRand (256 was relatively slow).
• In SeedStartup, 256 bits of entropy are generated, using RdSeed (preferably) or RdRand (otherwise).

[practicalswift]

While you're changing random.cpp: isn't the std::move on L562 without any effect? Could be removed?

[sipa]

@practicalswift MixExtract intentionally takes an rvalue reference, so that callers must either pass in a temporary, or use std::move explicitly (as the hasher object becomes useless after the call).

[sipa]

@gmaxwell Wow, I didn't know about those failure modes of RdRand and RdSeed. Rewrote things a bit to take that into account. RdRand is now retried up to 10 times (and ignored after that). RdSeed is retried indefinitely (with a pause in between). When using RdRand for 256-bit seeding, it's invoked 1024 times and XORed to produce each 64 bit group.

[gmaxwell]

utACK

[Empact]

Concept ACK. Apologies if any of the above is particularly naive. :P

[gmaxwell]

ACK

[gmaxwell]

Aside, we might want to consider this one a bug fix, since technically we weren't using rdrand quite correctly before. OTOH, the use of rdrand was entirely non-critical... sooo...

[laanwj]

So to be clear: this doesn't result in a CPU with broken and/or backdoored RDRAND or RDSEED instruction to generate vulberable private keys?

[sipa]

@laanwj Not trivially, at least. The output of the rdrand/rdseed is mixed with other entropy using SHA512 to produce output and the new state.

In theory a backdoored CPU could try to infer what variable is going to store entropy, and try to control that directly.

[laanwj]

Thanks!

In theory a backdoored CPU could try to infer what variable is going to store entropy, and try to control that directly.

Sure—I meant when say, only those instructions were made to return a fixed value, not anything more advanced/complex. Like a bugdoor with plausible deniability.

[laanwj]

Code review utACK 1435fab
I have no hardware to be able to test this on.
(if you do, /proc/cpuinfo will show the rdrand and/or rdseed under flags)

[JustinTArthur]

ACK 1435fab on macOS x86_64 on Intel Core i7-7920HQ CPU @ 3.10GHz (has RDRAND & RDSEED).

2019-02-13T19:22:30Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2019-02-13T19:22:30Z Using RdSeed as additional entropy source
2019-02-13T19:22:30Z Using RdRand as an additional entropy source

Functional and unit tests pass.

[sipa]

Tested on a system with RdRand but no RdSeed; tests pass, bitcoind runs fine, and reports only "Using RdRand as an additional entropy source".

[gmaxwell]

Tested on a system with no rdrand/rdseed, and it didn't catch fire. does @luke-jr maybe have a 32-bit system with rdrand/rdseed?

[gmaxwell]

@laanwj To expand on Pieter's response. Our mixing construction is designed to be secure against adversarial inputs generated by an attacker that can also inspect the entire process state unless the attacker can attack SHA512 in a very serious way (e.g. construct a suffix to a message being hashed that causes a specific hash value).

There are various standards for combining entropy sources that just xor the sources. The construction we're using is obviously stronger than those. If we had just xored the state then a malicious rdrand could inspect and return the current state (perhaps xored with a constant) in order to override it, and even plausibly do so as a bugdoor (e.g. oops we accidentally failed to update the register). I just mention this to point out that what we're doing is stronger than something other people think is acceptable...

[pstratem]

@gmaxwell
Linux debian 4.9.0-8-686-pae #1 SMP Debian 4.9.130-2 (2018-10-27) i686 GNU/Linux 2019-02-14T21:30:29Z Using RdSeed as additional entropy source 2019-02-14T21:30:29Z Using RdRand as an additional entropy source