On Thu, Mar 24, 2022 at 02:10:26PM +0800, Sandy Harris wrote: > NIST have a project called Entropy as a Service; the main goal seems > to be to provide adequate entropy even on IoT devices which may have > various limitations. > https://csrc.nist.gov/projects/entropy-as-a-service > > I have not yet looked at all the details but -- since Linux runs on > many IoT devices and on some of them random(4) encounters difficulties > -- I wonder to what extent this might be relevant for Linux. There is more detail about the proposal here: https://csrc.nist.gov/Projects/Entropy-as-a-Service/Architectures My initial reactions: 1) This is not a matter for the kernel, but for userspace to implement, since it involves multiple HTTP (yes, really, HTTP, not HTTPS) and NTP exchanges --- the crypto is done explicitly since presumably the designers didn't want to assume the IOT has a comment and bug-free(tm) implementation of HTTPS. Probably a good idea.... 2) The scheme only works if you assume that there is no collusion between the operators of the various remote servers used in the protocol. 3) NIST recognizes this, and has the following warning: WARNING:The resulting from Step 6 of the protocol random data shall not be used directly for constructing cryptographic keys with it or as a seed to a DRBG. Instead, known cryptographic mechanisms for combining multiple random data sources shall be used to mix random data obtained from multiple remote EaaS instances with local, with respect to the client system and the HRT device, randomness to create a seed for a NIST approved DRBG. Such cryptographic mechanisms are known in the trade as entropy/randomness extraction. It is strongly recommended at a minimum two independent EaaS instances located in different geopolitical locales be used as remote sources.... My conclusion is that it's not snake oil, but it's not a magic bullet, either. TNSTAAFL. - Ted
