[Cryptography] "Entropy as a Service: A New Resource for Secure Development"
phill at hallambaker.com
Mon Aug 26 09:34:42 EDT 2019
On Mon, Aug 26, 2019 at 1:01 AM Bill Cox <waywardgeek at gmail.com> wrote:
> On Sat, Aug 24, 2019 at 6:40 PM Jerry Leichter <leichter at lrw.com> wrote:
>> OK, this one has me puzzled. I can't figure out if they are talking
>> about better entropy generators running within individual machines, or some
>> kind of centralized entropy generation service (secured how?) or ... what,
>> I guess everything the becomes a buzzword is someone's business
>> -- Jerry
>> The cryptography mailing list
>> cryptography at metzdowd.com
> It's just a bad paper
> <https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=920992>, and a
> confusing article based on it. Here's the heart of their protocol:
> The client makes a HTTP GET request to the EaaS server, with the number of
>> bytes of random data to return, and its own public key, which is used to
>> encrypt the returned payload.
> Pretty funny. Encryption requires a secret that potential attackers do
> not know. To get such entropy, use this protocol. To use this protocol,
> you require a secret (the private key) that potential attackers do not
> I run into this silly concept now and then. IIRC, the "Entropy Key" even
> has an Entropy-as-a-Service feature for encrypting random numbers to
> multiple servers in a data center. It cracks me up that folks who know
> enough to make a decent TRNG don't understand why you can't just do a DH
> key exchange, and send the remote server the entropy it needs to do a
> secure DH key exchange.
Rather than talking about 'random numbers', I prefer the term 'unguessable'.
An unguessable number must be random but a random number can be guessable.
In particular if it starts from a guessable seed. When Netscape first
started working on navigator, I spent several weeks trying to explain to
the guy who began the SSL protocol that putting 30 bits of ergodicity into
MD5 would not produce 128 bits of randomness.
Just about the only (cryptographic) use I could see for this service would
be to initialize the random numbers in hardware devices during manufacture.
And even then I would probably prefer to have multiple sources and use a
digest function to combine them. And I would want to have ceremony aspects
to ensure none of the services/devices were jiggered. And even then, I
would not (fully) trust a manufacturer's claim to have done it properly.
So for example, my IoT device initializer consists of a randomness service
that delivers random numbers to the provisioner. I can test the provisioner
in isolation by connecting it to a known stream of data and checking that
its behavior matches what I expect.
Next I can construct a more trustworthy source of randomness by combining
three independent sources and then checking the combiner in isolation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography