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: Randall via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 6 Mar 2023 08:54:13 -0500
On Monday, March 6, 2023 8:08 AM, Cristian Rodríguez wrote:
>On Sun, Mar 5, 2023 at 1:33 PM Randall via curl-library <curl-library_at_lists.haxx.se>
>wrote:
>> I have a curl built with OpenSSL. The built of OpenSSL uses hardware
>> randomization on the platform using _rdrand64(). When I use libcurl,
>> typically through git, I end up with an open to PRNGD, which is not
>> desirable. I'm wondering whether there is a configuration setting that
>> I am missing from curl to force this, or whether I should contribute
>> code to access the x86 hardware randomizer directly. There is no
>> /dev/urandom or /dev/random on this platform, aside from it being
>> POSIX compliant. Curl is configured as follows:
>>
>> CFLAGS="-c99" CPPFLAGS="-D_XOPEN_SOURCE_EXTENDED=1 -WIEEE_float
>> -I/usr/local/openssl/include" LDFLAGS="-L/usr/local/lib" ./configure
>> --with-ssl=/usr/local --with-ca-path=/usr/local/ssl/certs
>> --disable-pthreads --disable-threaded-resolver --enable-ipv6
>>
>> Thanks in advance,
>> Randall
>>
>> --
>> Brief whoami: NonStop&UNIX developer since approximately
>> UNIX(421664400)
>> NonStop(211288444200000000)
>> -- In real life, I talk too much.
>
>I strongly suggest you against this approach, There are buggy CPUs with buggy
>rdrand, there are a number of pitfalls.
>Most current operating systems have either getentropy, getrandom, arc4random or
>a documentred platform-specific RNG. USE THAT INSTEAD.
>
>If there is really only rdrand (I really doubt that) on this exotic system, google "fast
>key erasure rng AES-NI"
>
>something like https://github.com/jedisct1/aes-stream should do it.
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.
Date: Mon, 6 Mar 2023 08:54:13 -0500
On Monday, March 6, 2023 8:08 AM, Cristian Rodríguez wrote:
>On Sun, Mar 5, 2023 at 1:33 PM Randall via curl-library <curl-library_at_lists.haxx.se>
>wrote:
>> I have a curl built with OpenSSL. The built of OpenSSL uses hardware
>> randomization on the platform using _rdrand64(). When I use libcurl,
>> typically through git, I end up with an open to PRNGD, which is not
>> desirable. I'm wondering whether there is a configuration setting that
>> I am missing from curl to force this, or whether I should contribute
>> code to access the x86 hardware randomizer directly. There is no
>> /dev/urandom or /dev/random on this platform, aside from it being
>> POSIX compliant. Curl is configured as follows:
>>
>> CFLAGS="-c99" CPPFLAGS="-D_XOPEN_SOURCE_EXTENDED=1 -WIEEE_float
>> -I/usr/local/openssl/include" LDFLAGS="-L/usr/local/lib" ./configure
>> --with-ssl=/usr/local --with-ca-path=/usr/local/ssl/certs
>> --disable-pthreads --disable-threaded-resolver --enable-ipv6
>>
>> Thanks in advance,
>> Randall
>>
>> --
>> Brief whoami: NonStop&UNIX developer since approximately
>> UNIX(421664400)
>> NonStop(211288444200000000)
>> -- In real life, I talk too much.
>
>I strongly suggest you against this approach, There are buggy CPUs with buggy
>rdrand, there are a number of pitfalls.
>Most current operating systems have either getentropy, getrandom, arc4random or
>a documentred platform-specific RNG. USE THAT INSTEAD.
>
>If there is really only rdrand (I really doubt that) on this exotic system, google "fast
>key erasure rng AES-NI"
>
>something like https://github.com/jedisct1/aes-stream should do it.
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.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-06