[cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]
coderman at gmail.com
Fri Dec 6 15:50:29 EST 2013
On Fri, Dec 6, 2013 at 12:07 AM, Patrick Pelletier
<code at funwithsoftware.org> wrote:
> Is the TRNG circuit small enough you could just slap down two of them, and
> use one to feed the NIST pipeline and use the other for raw entropy access?
yes, this would be useful, but not alone sufficient for an ideal solution.
for verification purposes, you may want to run in raw-TRNG with
userspace-RNGD to confirm behavior of the entropy sources as exhibited
by analysis of a large set of samples (this is very different than
"bit" entropy estimates or checks!). once the hardware is confirmed
to be working as expected for the physical noise source and collector
design in question, you switch to RDRAND mode for faster entropy use
with this underlying source.
that said, you want to protect the un-trusted concurrent consumers of
RDRAND/RDSEED from those accessing raw samples, so to support both
RDRAW and RDSEED/RDRAND concurrently and robustly across multiple
consumer, i would have:
1) a pair of noise sources per core for RDRAW calls (there is argument
for restricting this instruction to a privileged level)
2) a RDSEED/RDRAND CSPRNG per core with dedicated noise sources
separate from above, but select-able. that is to say, as an RDRAND
caller, i can request to use the physical noise source that i ran
RDRAW checks on earlier. or if i don't care as a low risk userspace
consumer, i can use any available RDSEED/RDRAND source. note that
being able to call RDSEED/RDRAND with a desired source may be
restricted to a higher privilege level.
3) an opt-in method of requesting CPU FAULT in event that any of the
sources or RDSEED/RDRAND AES processing chains fail catastrophically,
(all bit bias, broken rounds, etc.). also include config registers
for the sampling rate on the noise sources or other internal
this would resolve my currently yet to be sated desire for:
- an entropy instruction with raw sample access at maximum rate for a
paranoid/complementary userspace rngd mode of operation.
- the ability to perform extended and continually updated as needed
checks against a very large number of samples from a source before
using in the optimal throughput RDRAND/RDSEED mode. (raw access with
AES-NI mixing is pretty fast too :)
- entropy run-time verification with strong fail-secure guarantees
that can be leveraged by the operating system to enforce mandatory
hardware entropy availability requirements. E.g. fail to boot if
hardware entropy is broken, and CPU FAULT to alert OS if hardware
entropy generation becomes unexpectedly unavailable.
this design is also much more complicated to implement, given the
requirements. see compelling reasons to keep it simple; reducing
complexity in favor of robustness.
there is probably an elegant middle ground between always available
maximum performance and restricting certain modes or availability of
the instructions for simplified design and re-use... the joys of
P.S. in the VIA Padlock engine they simply provided raw access with
optional whiteners, checks. this meant that you always had to run a
userspace entropy daemon to configure and use XSTORE correctly, with
sanity checks, before mixing into the kernel entropy pool at
conservative entropy density. the details on doing this properly are
many, and for another thread :)
More information about the cryptography