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?
Date: Thu, 24 Mar 2022 21:45:56 -0400 [thread overview]
Message-ID: <Yj0e1MOaneLNMHim@mit.edu> (raw)
In-Reply-To: <CACXcFm=UTJ_wJL0w4=4kD5xcN+n-oi_4zmaxQqPunQGsPqhO1g@mail.gmail.com>
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
prev parent reply other threads:[~2022-03-25 1:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 6:10 Entropy as a Service? Sandy Harris
2022-03-25 1:45 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yj0e1MOaneLNMHim@mit.edu \
--to=tytso@mit.edu \
--cc=Jason@zx2c4.com \
--cc=linux-crypto@vger.kernel.org \
--cc=sandyinchina@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).