<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Matt, thanks for the clarification. I’ve looked at the DRBG setup code dozens of times and it never clicked.<div class=""><br class=""></div><div class="">It seems we’re down to making the DRBGs and, perhaps, the seed source available using fetch.</div><div class="">That doesn’t seem anything like as difficult.</div><div class=""><br class=""></div><div class=""><br class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>Pauli<br class="">-- <br class="">Dr Paul Dale | Distinguished Architect | Cryptographic Foundations <br class="">Phone +61 7 3031 7217<br class="">Oracle Australia</div><div><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 24 Sep 2019, at 6:32 pm, Matt Caswell <<a href="mailto:matt@openssl.org" class="">matt@openssl.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class="">On 24/09/2019 01:17, Dr Paul Dale wrote:<br class=""><blockquote type="cite" class="">This started in #9954, the topic of RAND being used by the legacy provider came up (in the context of DES). The abridged version is:<br class=""><br class="">* @levitte suggested the possibility of making RAND detachable.<br class="">* I noted that this was desirable and in fact necessary for FIPS.<br class="">* @mattcaswell added that the DRBGs and seeding is available inside the FIPS provider.<br class=""><br class=""><br class="">That the FIPS provider includes a copy of the relevant RAND files, means it can satisfy internal requests for random numbers.<br class="">However, external entities (TLS stack, user applications) won’t git FIPS approved random numbers.<br class=""><br class="">I can’t see currently an alternative to making the RAND functionality fetchable.<br class=""></blockquote><br class="">I think making RAND fetchable is highly desirable and should be done (I had<br class="">always assumed we would do this).<br class=""><br class=""><blockquote type="cite" class=""> I also suspect it will need to be per library context which might interfere with the per thread DRBGs we’re using.<br class=""></blockquote><br class="">I see no problems here. The RAND code is already library context aware. You get<br class="">per thread DRBGs for each OPENSSL_CTX. For example calling<br class="">OPENSSL_CTX_get0_private_drbg() will get you the private DRBG for the current<br class="">thread in the specified OPENSSL_CTX. RAND_DRBG_get0_private() does the same<br class="">thing for the default OPENSSL_CTX.<br class=""><br class=""><br class=""><blockquote type="cite" class="">As for what to fetch: the DRBG instances and the seed material source would be ideal, although we don’t need the seed source for FIPS (so long as the DRBGs seed from inside their own provider).<br class=""></blockquote><br class="">I had always assumed we would fetch DRBG instances.<br class=""><br class="">Matt<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class="">Thoughts or input anyone?<br class=""><br class=""><br class="">Pauli<br class=""><br class=""></blockquote></div></div></blockquote></div><br class=""></div></body></html>