<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019 at 1:01 AM Bill Cox <<a href="mailto:waywardgeek@gmail.com">waywardgeek@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 24, 2019 at 6:40 PM Jerry Leichter <<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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, exactly.<br>
<br>
I guess everything the becomes a buzzword is someone's business opportunity....<br>
<br>
<a href="https://www.business2community.com/cybersecurity/entropy-as-a-service-a-new-resource-for-secure-development-02230605" rel="noreferrer" target="_blank">https://www.business2community.com/cybersecurity/entropy-as-a-service-a-new-resource-for-secure-development-02230605</a><br>
<br>
-- Jerry<br>
<br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a><br>
<a href="https://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">https://www.metzdowd.com/mailman/listinfo/cryptography</a></blockquote><div><br></div><div><div>It's just <a href="https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=920992" target="_blank">a bad paper</a>, and a confusing article based on it. Here's the heart of their protocol:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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. <br></div></blockquote><div><br></div><div>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
know...<br></div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Rather than talking about 'random numbers', I prefer the term 'unguessable'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Next I can construct a more trustworthy source of randomness by combining three independent sources and then checking the combiner in isolation.</div></div></div>