Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Thu, 24 Mar 2022 21:45:56 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Sandy Harris <sandyinchina@gmail.com>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: Re: Entropy as a Service?
Message-ID: <Yj0e1MOaneLNMHim@mit.edu>
References: <CACXcFm=UTJ_wJL0w4=4kD5xcN+n-oi_4zmaxQqPunQGsPqhO1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACXcFm=UTJ_wJL0w4=4kD5xcN+n-oi_4zmaxQqPunQGsPqhO1g@mail.gmail.com>
Precedence: bulk

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