Path to a NodeJS demo

[Utopiah]

The servers provided, in particular reverse proxies like nginx, cover most Web services.

Still numerous ones rely on NodeJS directly via popular framework like Express itself allowing some customization.

My understanding is that NodeJS ships with OpenSSL and defaults to it with its cipher suite that can be customized.

Consequently I believe a demo could be made by

1. compiling open-quantum-safe/openssl
2. using a binary compatible NodeJS version and force to use oqs openssl via LD_LIBRARY_PATH knowing the related maintaining position and that numerous issues have been opened on the topic so to verify via node -pe process.versions
3. alternatively build NodeJS dynamically linking oqs openssl (via e.g the FIPS support example )
4. run the Express demo limited to a specific cipher with e.g node --tls-cipher-list='falcon512' server.js then open it with oqs chromium

Does this seem like a realistic path?

Edit: relying on nodejs --shared-openssl with the oqs-provider plugin, cf details on providers, seems like a more maintainable path.

[baentsch]

relying on nodejs --shared-openssl with the oqs-provider plugin, cf details on providers, seems like a more maintainable path.

If you hadn't added that, that'd been my recommendation, too. We really want to move off oqs-openssl111...

Now, the bigger issue I see is that our code does not provide a cipher (in either oqsprovider or oqs-openssl), but only KEM and signature algorithms. As I don't know enough about Express there's probably some more investigation required... If this can make use of signature or KEM algorithms, then, yes, the path you propose sounds doable. Feel free to keep us posted on what you find going forward (or want to bounce off further ideas).

[davidkel]

I've started to have a look at this and was looking to use prebuilt nodejs binaries and add oqs to the environment to run nodejs code. Unfortunately I hit a problem using MLDSA signatures with openssl throwing an error

ERR_SSL_CA_MD_TOO_WEAK

And I assume this is due to node using openssl 3.0.15 as I have built a version of node which dynamically links a newer version of openssl and have not seen this issue. The problem with node is the pre-built binaries statically link openssl so the demo would have to build node from source with takes about 40 minutes on machines I have tried (not tried in github actions though). So wondering if this is something that's undesirable or whether that would be acceptable ?

[SWilson4]

I believe that error is indeed due to the OpenSSL version.

Perhaps we could build a version of Node with dynamic linking once in CI, cache it, and use the cached binary in future runs (possibly with updated version(s) of OpenSSL). Does that approach sound feasible?

Also looping in @baentsch as the OpenSSL / OQS provider expert.

[davidkel]

@SWilson4 Yep, that sounds good, I assume we can invalidate the cache if we want to change the version of node. If it's at a file level (so it invalidates when a file changes) then we would need to have perhaps a separate file controlling the build of node and a file for all the other stuff. Definitely need to warn users who like to build themselves that it takes a very long time. I assume that github actions has the ability to cache persistently of course. Not something I've looked at for github actions

[baentsch]

Also looping in @baentsch as the OpenSSL / OQS provider expert.

Arguably no expert needed :-) "md too weak" seems like an FAQ, see e.g., here or here.

To optimize build time, my strong recommendation is to build using a recent openssl version, ideally "master": In that case, all problems around linking in oqsprovider are gone (as it's not necessary any more :-) Also, build time should drop substantially as neither liboqs or oqsprovider need to be built but just openssl (and that takes about 50secs on my little laptopt :). Can't comment on node, though: Do you have a link to a build script or run to check where's the bottleneck @davidkel ? 40mins sounds massive.... But again, a draft PR with your work would be great to put some more eyes on this.

[davidkel]

@baentsch I do a lot of builds of apps that use openssl/oqs and nodejs is by far the worst for me taken the longest (and it doesn't include openssl, liboqs or oqsprovider as they are prebuilt) and on some build environments it would take 40 mins (laptop not so bad but they are more powerful than provisioned build envs). Certainly happy to try doing some builds on github actions to see how they fair so will look to getting a draft PR going to see how it does.

[davidkel]

I don't know if this project gets favourable github runner treatment, but I've now run a build of nodejs in my fork and the nodejs part takes 1 hour 18mins (Best time on my Laptop was 32 mins). You can see the results here. https://github.com/davidkel/oqs-demos/actions/runs/13694604395/job/38294097998 I can still look at caching the nodejs part of the build so that the cache is used if no changes are made to the nodejs specific part of the dockerfile. Given the length of time here and that the oqs/openssl part takes about 6 minutes not sure it's worth moving to openssl master to save a couple of mins Let me know what you would be happy with here.

[baentsch]

Let me know what you would be happy with here.

I'm happy with anything that helps users -- and a ready-build PQC-Node image will. We can optimize build time later and/or decide when to run the build in CI. So, a PR along these lines would be the next step for me.

[davidkel]

@baentsch @SWilson4 I've created a PR for nodejs here https://github.com/open-quantum-safe/oqs-demos/pull/362

On my github actions I was seeing build times of between 1hr 20mins and 1hr 45mins. On my machine I could build it in 35 mins but the machine is powerful with lots of available cores.

[davidkel]

@SWilson4 @baentsch I believe this issue is now resolved