implement {sign|verify} message signature functionality

[petrovr]

This functionality is available for first in OpenSSL 3.4.
High level functions are EVP_PKEY_sign_message_init(3) and EVP_PKEY_verify_message_init(3).

This is request oqs-provider to implement such functionality.

[baentsch]

Thanks for this proposal @petrovr . Could you please be a bit more specific in what openssl functions currently don't work and which ones should, e.g., by way of command sequences we could add to https://github.com/open-quantum-safe/oqs-provider/blob/main/scripts/runtests.sh or any of its sub-scripts? Basic sign/verify already is being tested here.

[RodriM11]

I imagine the proposal comes from being able to execute PQ/hybrid schemes from EVP_PKEY_sign_message_init interfaces, which in current oqsprovider is not possible since oqs_signature_functions does not have them defined.

I think the really interesting question is what should be the expected behavior? For purely PQ signatures, I would argue that it would be a straightforward and clear addition, since they don't have a limit on the size of the message to be signed, so I believe that by adding OSSL_FUNC_signature_sign_message_init_fn to the same sign/verify functions it could be achieved.

For hybrid schemes, the history is different. Current signature implementation via oqsprovider handles arbitrary message by hashing the message for signature scheme. By including this functionality, how should we proceed?

• Should we only allow arbitrary message length signature for PQ schemes?
• Should we just propagate the same behavior for the message interface as we have now?
• Should we account for message digests that are being set?
• Should we do something else?

[petrovr]

Dunno how OpenSSL implements ML-DSA.

Report is based on https://gitlab.com/secsh/pkixssh/-/blob/mldsa_demo/ssh-mldsa.c

Related OpenSSL documentation issue - openssl/openssl#29088
It seem to me 6 macros and respective functions are added in OpenSSL 3.4

---

With OpenSSL 3.5 :
new : EVP_SIGNATURE_fetch -> EVP_PKEY_CTX_new_from_pkey -> EVP_PKEY_sign_message_init -> ...
old: EVP_DigestSignInit -> EVP_DigestSign -> ...

Similar for verification.

Tested all four combinations:

• sign-new vs verify-new
• sign-new vs verify-old
• sign-old vs verify-new
• sign-old vs verify-old

---

About test cases: grep for new functions in OpenSSL apps directory does not return results i.e. does not exist utility that allows testing.

---

I know that oqs does not provide ML-DSA if OpenSSL >= 3.5.
Question is more for other algorithms.

[RodriM11]

Yes, the problem you report is clear: the sign/verify_message interface won't work since oqsprovider is not currently handling those (i.e. OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_INITand similar dispatches are not being considered).

The core question to address this issue is how should we include it. For pure PQ signatures I think, as described above, that it is somehow straightforward: it can be added and handled in the same way as common EVP_PKEY_sign_init and similar, since PQ DSA algorithms can handle arbitrary signatures.

The more subtle question is hybrid signatures: Current oqsprovider implementation is hashing the message for hybrids, so I would argue that this implementation currently would exactly match the sign/verify_message. And then, the question would be what to define for the standard sign/verify interface? Should we implement a second sign/verify interface in which the message is not hashed (i.e. is expected to already be)? Should we use the same logic here? Should we use this opportunity for a different digest logic? None of the above?

[RodriM11]

In fact, I would argue the following: current implementation is more close to the sign/verify_message interface being proposed to be added. And direct sign would be more close to uncommenting here (i.e. relying on pre-performed hashes)

[baentsch]

In fact, I would argue the following: current implementation is more close to the sign/verify_message interface being proposed to be added. And direct sign would be more close to uncommenting here (i.e. relying on pre-performed hashes)

Argh, indeed -- you're quite right @RodriM11 . Apologies for not having noticed this new set of functions making their debut already in 3.4 :-( Yes, indeed the current oqsprovider logic is pretty close to those interfaces because the PQ algs have always been geared to the usage style described in the design doc.

In sum, Yes, this looks like a good addition for SIG algs, only requiring additional support as per doc for

OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_INIT
OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_UPDATE
OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_FINAL
OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_INIT
OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_UPDATE
OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_FINAL

I would argue that it would be a straightforward and clear addition, since they don't have a limit on the size of the message to be signed, so I believe that by adding OSSL_FUNC_signature_sign_message_init_fn to the same sign/verify functions it could be achieved.

+1

For hybrid schemes, the history is different. Current signature implementation via oqsprovider handles arbitrary message by hashing the message for signature scheme. By including this functionality, how should we proceed?

Should we only allow arbitrary message length signature for PQ schemes?

No, also for hybrids -- the goal of oqsprovider is to deliver the same functionality for all algorithms it makes available ("orthogonality") and I'd think that can be achieved here too.

Should we just propagate the same behavior for the message interface as we have now?

That'd be the easiest I'd say.

Should we account for message digests that are being set?

Don't we already permit that (respond to OSSL_SIGNATURE_PARAM_DIGEST being set)? Then why not act on it? The logic is there and arguably needs to be "wired up" in these 6 new functions, no?

Should we do something else?

I don't see a reason for that. What (else) would you propose @RodriM11 ?

About test cases: grep for new functions in OpenSSL apps directory does not return results i.e. does not exist utility that allows testing.

In ´openssl´ test directory there's testing for this. But indeed, apparently nothing exists at a command line level as we use it in the oqsprovider testing :-( Wonder whether that'd be a worthwhile addition to OpenSSL? At the very least, this seems like a sensible addition to openssl speed (delivering performance data varying the length of input data beyond the length of a SHA256 (a limitation that it seems also I'm responsible for :-() for "streaming" algorithms, from RSA-SHA256 to any PQ-hybrid).

[RodriM11]

I don't see a reason for that. What (else) would you propose @RodriM11 ?

I was just opening the door to other proposals. To me, one of these two options should be adopted:

• Either we include the sign/verify_message functionality in exactly the same manner as the sign/verify (with the required modifications to provide an update/final interface instead of a one shot call), and the current sign/verify stays as is.
• Or we employ the current sign/verify for the new sign/verify_message, and rely on pre-performed hashes for the sign/verify interface.

I may feel a little stronger towards the second one, as I think follows more closely to what the OpenSSL APIs intended, but would like to hear other opinions.

[baentsch]

Do I understand you right in that your option 2 basically is to re-purpose (mostly rename+add update) the current sign/verify code for the new _message APIs and simplify the current sign/verify APIs by those then failing to accept anything that is not pre-hashed/"short" enough (only for hybrids, of course, as the PQ algs will still accept longer messages), @RodriM11 ?

I'd agree that comes closer to what the OpenSSL APIs intend. But this runs the risk that people relying on the current oqsprovider behaviour will have to change.

That said, I have no clue how many people do that and agree that they should change to the 3.4 APIs if they wanted to ("stream").

Thus, if I got everything right (?), I fully support option 2. It also seems better aligned with the original request that started this discussion.

[RodriM11]

Yes, that would be exactly my proposal. But, as you note, this would change the behavior underneath, so it would have to be sufficiently noted in the release notes of the version that incorporates this new functionality.