Dilithium 3.1 update

[bhess]

Dilithium was recently updated to version 3.1. The new implementation needs to be pulled and the KAT need to be updated.

[baentsch]

As it's still some effort (particularly when changing names) to push algorithm updates through all downstream projects, what about doing only one PR to resolve this and #896 and #899? Further, does this upgrade entail an (openssl) OID update, too?

[bhess]

Agreed, will do a common PR with #896 and #899 (suggest priority for #889). There isn't a name change this time. I will check if it is safe to dedicate the current OID for Dilithium 3.1 or if it needs an update. The current OIDs were added just recently to oqs-openssl (before a new release), so it could still be fine to do the update without an OID change from an openssl-view. What is your opinion on that?

[baentsch]

What is your opinion on that?

Given those OIDs are in the "OQS-public" only since a few days, I don't see much of a problem retaining those ("3.0" ones). Also, as we didn't do a regular release anyone using this already clearly does at his own risk. There'd only be a (minimal) issue to OQS if those OIDs had been in use for longer in other, proprietary/in-house software and persistent artifacts (aka certs) had been created with them and there'd be people expecting interoperability with OQS. You know the maintainer of those OIDs and can determine the answer for this.

What does make me wonder, though, is how likely it is that Dilithium 3.2, 3.3... appears soon, given it was less than a week between 3.0 was integrated and a 3.1 becomes available. Or in other words: Would it be sensible to wait resolving this issue a bit until this code settles?

[bhess]

Given those OIDs are in the "OQS-public" only since a few days, I don't see much of a problem retaining those ("3.0" ones). Also, as we didn't do a regular release anyone using this already clearly does at his own risk. There'd only be a (minimal) issue to OQS if those OIDs had been in use for longer in other, proprietary/in-house software and persistent artifacts (aka certs) had been created with them and there'd be people expecting interoperability with OQS. You know the maintainer of those OIDs and can determine the answer for this.

Thanks, this confirms my thought. I was mainly wondering about the openssl-side and if it is considered a rolling release or bound to a liboqs-release.

What does make me wonder, though, is how likely it is that Dilithium 3.2, 3.3... appears soon, given it was less than a week between 3.0 was integrated and a 3.1 becomes available. Or in other words: Would it be sensible to wait resolving this issue a bit until this code settles?

Not likely, the short time between integration and 3.1 was more a coincidence. But I would suggest to resolve this issue only after the upstream-code has been tagged.

[baentsch]

or bound to a liboqs-release

OIDs would rather be bound to an OQS-OpenSSL release -- which in turn is bound to a liboqs release. Thus, no-one should rely on "bleeding edge" -- but you never know :)

But I would suggest to resolve this issue only after the upstream-code has been tagged.

Good approach. Thanks.

[baentsch]

Closed with #923