More SPHINCS+ variants?

[anhu]

Now that we know SPHINCS+ is moving on to standardization, would it be a good idea to enable more variants to get a better idea about how the various variants compare to each other?

[baentsch]

Well, my dream for a post-standarization liboqs was one that was slimmer and more amenable to actual use/integration (less complexity due to plethora of algorithms).

Adding more SPHINCS+ to it would achieve the exact opposite: If I counted right, liboqs currently supports 62 QSC sigs of which 36 already are SPHINCS+ variants -- nearly 2/3! Moreover, it's extraordinarily slow (about 1% of the fastest dilithium's speed when signing on x64 ). In combination, this means that SPHINCS already is the by far biggest CO2 emitter in the library (causing CPU cycles in just CI and testing of those many slow algorithms). Adding more variants could be construed as a violation of the Paris Agreement.... What about the suggestion in turn to add/test one new variant for each 2 that we delete?

"Fun" aside: We discussed the option to create different liboqs variants (standard(ized) use, research use, round 4 evaluation use); so if you can suggest a way to really parameterize SPHINCS (vs. copying the same code base with different parameters over and over again), that'd be a good change (next to making it faster).

[anhu]

I didn't see the word "no" in there, but it sort of felt like a "no" so I'm going to take that as a "no" . Thank you!! :)

[anhu]

Thanks @baentsch. Well, I can sympathize with your thoughts. Things are supposed to be simpler now that the announcement has been made, but the SPHINCS+ submission has 36 variations which is not simpler.

As for which ones make sense and which ones can be dropped, well, there are many that are far more qualified than I who can make better suggestions.

Thanks for keeping this conversation going!!

Warm regards, Anthony

[baentsch]

the SPHINCS+ submission has 36 variations which is not simpler

So liboqs already contains all 36?!? Then which further variants did you initially suggest to additionally enable? Looking at https://openquantumsafe.org/benchmarking/visualization/speed_sig.html I can see all 36 being measured (against each other and the other candidates) -- in 3 build variations and 3 platforms.

[anhu]

Yes. liboqs has all 36 BUT your openssl fork only has some of them. So I was suggesting that the openssl fork support more of them. Sorry I should have made that more clear. I just sort of assumed you knew I was talking about the openssl fork as this discussion is in the openssl repo.

[baentsch]

Ahh - no, indeed, that detail eluded me, Sorry :-( For (OQS-)OpenSSL the answer is extremely simple: No :-)

Reason: OpenSSL is geared to a very small number of different (signature) algorithms and we have to be very careful how many to activate without blowing some internal data structures: The key constant is SSL_PKEY_NUM: This is defining the maximum number of PK algorithms supported; For standard OpenSSL the number is 9, for OQS-OpenSSL we're at 45 -- thus already taking some risks with (32-bit) algorithm flag manipulations somewhere (forgot where, would need to dig). This is a key reason why we can't simply activate all OQS algorithms in OpenSSL(1.1.1) -- and why it still is a bit of a challenge to enable pluggable (QSC) signature algorithms in OpenSSL3 (via the oqs-provider).

[anhu]

Yes. This response makes a lot more sense.

openssl#10512

I remember those discussions fondly. :)

Thanks for all the time you've spent in this conversation!

Warm regards, Anthony

[baentsch]

Thanks for all the time you've spent in this conversation!

And Thanks in turn for your patience with my initial wrong assumption about what the ask was -- extending the PK/sig alg list in OpenSSL just was so "hardwired" as "hard-to-impossible" in the back of my mind that the thought never occurred that this is about OpenSSL -- but clearly my mistake to not have properly checked :-(. Best, --Michael