On Fri, Dec 6, 2013 at 12:07 AM, Patrick Pelletier <c...@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 tune-ables. 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 engineering! best regards, 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 :) _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
