Replies: 3 comments 5 replies
-
|
I guess what you are saying here is that your HSM does not support multipart for ML-DSA ? At the moment there is no way not to use C_SignUpdate, and you should not see a call to C_Sign at all, because that would end the operation. If you could provide a debug log from the operation I can try to see if there is anything we can do on the OpenSSL side to improve the situation. |
Beta Was this translation helpful? Give feedback.
-
|
Actually we do have support for one shot operations, sorry, so I suspect you may be calling OpenSSL APIs in a way that is not correct. Can you should what OpenSSL calls you are using to perform the sign operation ? |
Beta Was this translation helpful? Give feedback.
-
|
thanks Simo, and thanks for all the work you do :-) amazing work here :-) Yes you are correct the hsm does not yet support multipart signing in pkcs11 api (for MLDSA), however should have it in the near future :p The openssl call for MLDSA sign and verify (and export public key) all work good. very clean pkcs11 debug log. the openssl req is the only one with issue and fails with (mech is single part only) => jira for that one.... :p but yep i was wondering if there was some kind of buffer on the length of a message i saw with opensc there was some max buffer length on a call (512) a while back and that caused an issue...... i found some messages on that. (ok lets forget about opensc lol) if we could do a c_sign only and not a c_signupdate, that would definately fix this hsm use case in the short term until the jira for the hsm happens to allow pkcs11 3.2 multipart signing for MLDSA sign mech on the hsm side of things. these calls all work great for sign, verify, and export pub key sign: root@ubunt2510sw139:/opt/nfast# openssl pkeyutl -sign -inkey "pkcs11:token=accelerator;pin-value=1234;object=mldsa33" -out workload.sig5 -in workload.txt this does a c_sign and works great verify works great openssl pkeyutl -verify -in workload.txt -sigfile workload.sig5 -inkey "pkcs11:token=accelerator;pin-value=1234;object=mldsa33;type=public" -pubin ok now for the openssl req command that fails so 1st i had to manually set the CKA_ID's to non null so it wouldnt error out :p took me awhile to figure that one out but i had a util to do that (p11tool can do it for the priv key yah but wonks out on the public key :p but no worries i found another tool to do it) openssl req -key "pkcs11:token=accelerator;pin-value=1234;object=mldsa33" -new -out req.csr so yep this command works good for openssl req CSR's for RSA through latchset earlier versions, and also with the same hsm pkcs11 module. heres the debug, yes apologies only a c_signupdate there is no c_sign 2025-09-20 14:27:07 [7925] t40a712ad347f0000: pkcs11: 000008CB >> C_SignInit 2025-09-20 14:27:07 [7925] t40a712ad347f0000: pkcs11: 00000000 D NFC__hash_session 0x000008CB and of course we can see we dont have multipart yet in our provider 2025-09-20 14:27:07 [7925] t40a712ad347f0000: pkcs11: 000008CB Error: Mechanism is single part only but we are working on that :-) anything we can do on the latchset side to get this now into a c_sign? thanks! cheers! :-) |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately this is a problem deep into EVP_DigestSign(). I do not recall why we didn't add it, it may be due to the fact that technically ML-DSA does not allow what is traditionally a digest_sign API for OpenSSL as you can't select the digest for ML-DSA signatures. I'll use this investigation to open a bug to see if we can add it safely w/o breaking other assumptions in OpenSSL. |
Beta Was this translation helpful? Give feedback.
-
|
thanks Simo! appreciate the work on this :-) i have a jira to add multisign to the hsm provider as well!! :-) thanks cheers! |
Beta Was this translation helpful? Give feedback.
-
|
is it in 3.2 spec or 3.3 spec? i mean u can do hash for MLDSA using external mu case. for instance: steps to do external MU of MLDSA (shake 256 hash)
context could be 0 to 255 in length. ok! hash MLDSA case. thanks |
Beta Was this translation helpful? Give feedback.
-
|
PKCS#11 3.2 does not have support for external MU mechanisms, that is something that will be considered in 3.3, so literally we cannot support external MU cases at this time. As for multi-part, PKCS#11 3.2 does not explicitly say that ML-DSA should support multi-part, but there is nothing preventing an implementation from doing so. We will make it clear that ML-DSA can be implemented as multi-part in the 3.3 spec |
Beta Was this translation helpful? Give feedback.
-
|
we fixed this on our end of things :-) many thanks! cheers! :-) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
hi guys!
1st up, great job on the 1.1 release !
im testing with an HSM through pcks11 api.
ubuntu 25.10 with openssl 3.5.2 and latchset 1.1
When i do an openssl req with a pkcs11 URI to the HSM provider (not softhsm not yubijey :p) but a rack mounted hsm, the pkcs11 debug call shows
c signinit
c sign
c signupdate
so it goes to a multipart message for the MLDSA sign call for the openssl req (CSR generation)
is there a variable I can change in the latchset provider side to send a bigger c_sign to not do multipart MLDSA sign?
i dont want the signupdate. but just 1 c_sign and thats it.
hopefully you have a variable i can adjust maybe? and make bigger bytes?
i mean there is no standard for the max c_sign size is there??
the hsm side has a maximum size i know, but we didnt hit it yet as well.
thus im thinking there may be a preset max message size to do multipart if the data is bigger than i can adjust before i compile it.
100 dogecoins for this hahaha :-)
thanks guys!
Beta Was this translation helpful? Give feedback.
All reactions