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 17:08:40 -0500
On Monday, March 6, 2023 3:21 PM, Cristian Rodríguez wrote:
>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.
The issue here is far more extensive than just "me" using this. My organization, ITUGLIB (part of The Connect Community), is responsible for packaging curl, OpenSSL, git, and other products for use on NonStop servers, which are MPP architecture servers. While your suggestion makes sense for someone's basement server, it is unlikely that any HPE NonStop customer would download an unsanctioned PRNGD version that varies from the standard one delivered by the vendor (a.k.a. Hewlett-Packard Enterprises). Their current solution is a port of the Core Utils software RNG running through a single socket, which is not conducive to the high performance required by industrial grade high performance servers. This is simply not an option for my community.
Aside from that, putting an RNG many hops in an MPP away from the core where the requesting process is running means many (at least 3) orders of magnitude performance loss on a platform verified hardware RNG. I really do not want to cost customers this.
Do I know how to do this? Yes. Would anyone in the community use it? Not likely.
Is the answer that hardware RNG is not supported by curl at all? I would prefer to stick to the original question based on requirements as stated.
Date: Mon, 6 Mar 2023 17:08:40 -0500
On Monday, March 6, 2023 3:21 PM, Cristian Rodríguez wrote:
>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.
The issue here is far more extensive than just "me" using this. My organization, ITUGLIB (part of The Connect Community), is responsible for packaging curl, OpenSSL, git, and other products for use on NonStop servers, which are MPP architecture servers. While your suggestion makes sense for someone's basement server, it is unlikely that any HPE NonStop customer would download an unsanctioned PRNGD version that varies from the standard one delivered by the vendor (a.k.a. Hewlett-Packard Enterprises). Their current solution is a port of the Core Utils software RNG running through a single socket, which is not conducive to the high performance required by industrial grade high performance servers. This is simply not an option for my community.
Aside from that, putting an RNG many hops in an MPP away from the core where the requesting process is running means many (at least 3) orders of magnitude performance loss on a platform verified hardware RNG. I really do not want to cost customers this.
Do I know how to do this? Yes. Would anyone in the community use it? Not likely.
Is the answer that hardware RNG is not supported by curl at all? I would prefer to stick to the original question based on requirements as stated.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-06