Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: [Question] Forcing libcurl to use hardware randomization
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Cristian Rodríguez via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 6 Mar 2023 17:21:28 -0300
On Mon, Mar 6, 2023 at 10:54 AM <rsbecker_at_nexbridge.com> wrote:
> This platform has limited porting capabilities. The Xeon x86 HRNG is highly stable and verified on this platform - this is not one of the flakey HRNG processors. Its use has passed all sorts of randomness tests and is far better than PRNGD (can't even pass most jitter tests), which we are trying to avoid for its own issues. _rdrand64() is a provably valid and useful replacement for PRNGD on this platform. The OS does not have what you suggest, or we would have used it instead. All we are trying to do here is ensure that curl only uses randomness from OpenSSL and not from another source.
It should be pretty straightforward to change prngd to use rdrand or a
modern day RNG if you have this bottleneck. on a x86_64 system it
should output like from a few hundred mbps on the absolutely worst
case scenario..to gbps easily.
you don't have to use C .. the unix socket interface or the tcp
interface of prngd is likeñy a few lines of java (Is that what your OS
supports as higher level language right(???¡¡)) even more easy it
would be in golang or a supported scripting language but I do not know
what you really have available.
golang uses a "fast key erasure rng" as fallback
Java should have something decent as well.
Date: Mon, 6 Mar 2023 17:21:28 -0300
On Mon, Mar 6, 2023 at 10:54 AM <rsbecker_at_nexbridge.com> wrote:
> This platform has limited porting capabilities. The Xeon x86 HRNG is highly stable and verified on this platform - this is not one of the flakey HRNG processors. Its use has passed all sorts of randomness tests and is far better than PRNGD (can't even pass most jitter tests), which we are trying to avoid for its own issues. _rdrand64() is a provably valid and useful replacement for PRNGD on this platform. The OS does not have what you suggest, or we would have used it instead. All we are trying to do here is ensure that curl only uses randomness from OpenSSL and not from another source.
It should be pretty straightforward to change prngd to use rdrand or a
modern day RNG if you have this bottleneck. on a x86_64 system it
should output like from a few hundred mbps on the absolutely worst
case scenario..to gbps easily.
you don't have to use C .. the unix socket interface or the tcp
interface of prngd is likeñy a few lines of java (Is that what your OS
supports as higher level language right(???¡¡)) even more easy it
would be in golang or a supported scripting language but I do not know
what you really have available.
golang uses a "fast key erasure rng" as fallback
Java should have something decent as well.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-06