On Mon, Nov 22, 2021 at 11:02 PM Simo Sorce <simo@xxxxxxxxxx> wrote: > ... with my distribution hat on I > can say that FIPS is essential for us and any design must include an > option to be FIPS certifiable. I think I understand Ted's objections & I'm inclined to agree with them. See also this comment from Jon Callas: " The NIST AES_CTR_DRBG is mostly-okay. It's got a few issues " (see <https://eprint.iacr.org/2020/619.pdf>), but you can get " around them. I don't like that it takes a simple concept (a good block " cipher is a good PRP/PRF) and throws enough scaffolding around it " to make it hard to understand. I understand the reasons .., it just " bugs me. That said, people do want compliance with FIPS or various other standards. That raises a number of questions. One is for Stephan: would you care to submit patches for the current driver that ONLY make it FIPS (and/or European standards) compliant? No jitter, no stuff to allow different crypto, no choice to replace the driver, ..., just FIPS. Some of those might be good ideas, but they would not belong in a FIPS patch. I think that would have a much better chance of acceptance than your patches to date. There are also more general questions: The FIPS requirements for a deterministic RNG include a whole rat's nest of extras, notably various self-tests, which Stephan's patches might deal with. Or do any of the vendors have patches for that? FIPS defines DRNGs using either a block cipher or a hash, but we use a stream cipher. According to Wikipedia, several of the *BSD distros do the same. https://en.wikipedia.org/wiki/Salsa20#ChaCha20_adoption This seems reasonable to me, but could we persuade NIST to add that option? I've added John Kelsey (one of the FIPS authors) to the cc list in hopes of that. Failing that, the Blake hash function is based on Chacha https://en.wikipedia.org/wiki/BLAKE_(hash_function) Should we use that to get a more easily certified DRNG? Would that be as fast as Chacha alone? The FIPS also require that all the entropy inputs to the DRNG be certified. I think we have a problem there. I suspect that many of the random number instructions enabled by CONFIG_ARCH_RANDOM or the hardware RNGs enabled by CONFIG_HW_RANDOM could be certified, but that would need to be done by the vendors and the costs might be substantial. Are any already certified? Is there any vendor interest? Apart from those, the current driver gets entropy in several places. The comments have: * The current exported interfaces for gathering environmental noise * from the devices are: * * void add_device_randomness(const void *buf, unsigned int size); * void add_input_randomness(unsigned int type, unsigned int code, * unsigned int value); * void add_interrupt_randomness(int irq, int irq_flags); * void add_disk_randomness(struct gendisk *disk); * * add_device_randomness() is for adding data to the random pool that * is likely to differ between two devices (or possibly even per boot). * This would be things like MAC addresses or serial numbers, ... * * add_input_randomness() uses the input layer interrupt timing, as well as * the event type information from the hardware. * * add_interrupt_randomness() uses the interrupt timing as random * inputs to the entropy pool. Using the cycle counters and the irq source * as inputs, it feeds the randomness roughly once a second. * * add_disk_randomness() uses what amounts to the seek time of block * layer request events, ... Note that high-speed solid state drives with * very low seek times do not make for good sources of entropy, ... I think we should eliminate add_disk_randomness() since it does not work well on current hardware. Also, FIPS requires that entropy sources be independent & add_interrupt_randomness() depends on the same disk events so these sources may not be. A similar argument could be made for getting rid of add_input_randomness() but that would lose the event type information. Does that matter? The current driver also uses other sources, at least fast_mix(), add_timer_randomness(), random_get_entropy() and the gcc latent entropy plugin. Could/should those be simplified to get more easily audited or certified code? The driver also allows input of external data which is mixed into the pool & provides an ioctl to let a user with root privileges change the pool's entropy estimate. Do either of those violate the FIPS requirement that only certified entropy sources be used? I'd be happy to lose the ioctl (or better, all the entropy estimation machinery) but those have been part of the system for decades. I'd definitely want to keep the option to use external inputs.
