OASIS PKCS 11 TC

 View Only
  • 1.  Clarifications in specification of ML-DSA and SLH-DSA

    Posted 02-05-2025 03:32

    In the last few days, I have been contacted by 2 persons who had consulted PKCS#11 v3.2 working draft 08, to prepare for an implementation of ML-DSA in their applications. They had quite similar questions to make sure that their understanding of section 6.67 matches with ours. Triggered by that, I suggest to 

    • replace all occurences of "Hash ML-DSA" (with space) by "HashML-DSA" (without space) to match the notation in FIPS 204
    • reference the exact algorithms in FIPS 204 and add some words about the input data. See below a proposal for these extensions, marked as underlined text
    • add hash functions SHA512_224 and SHA512_256 to table 284, as these hash functions are also used in ACVP test data

    6.67 ML-DSA and HashML-DSA

    ML-DSA and HashML-DSA are mechanisms for signatures and verification, following the digital signature algorithm defined in [FIPS 204].

    6.67.5 ML-DSA

    The ML-DSA signature mechanism, denoted CKM_ML_DSA, is a mechanism for generating and verifying ML-DSA signatures as defined in Algorithm 2 ML-DSA.Sign and Algorithm 3 ML-DSA.Verify in [FIPS 204], using SHAKE256 as hash function. The data passed in is the message M.

    6.67.6 HashML-DSA Signature

    The HashML-DSA signature mechanism, denoted CKM_HASH_ML_DSA is a single part mechanism for generating and verifying pre-hash ML-DSA signatures as defined in Algorithm 4 HashML-DSA.Sign and Algorithm 5 HashML-DSA.Verify in [FIPS 204]. The data passed in is an already hashed message PHM.

    6.67.7 HashML-DSA Signature with hashing

    The HashML-DSA with hashing mechanism, denoted CKM_HASH_ML_DSA_<hash> where <hash> identifies a hash function as per Table 284, is a mechanism for single- and multiple-part signatures and verification for pre-hashed ML-DSA as defined in Algorithm 4 HashML-DSA.Sign and Algorithm 5 HashML-DSA.Verify in [FIPS 204]. The data passed in is the message M. This mechanism computes the entire HashML-DSA specification, including the hashing on token.

    Any comments to these editorial changes?



    ------------------------------
    Best regards,
    Dieter
    ------------------------------


  • 2.  RE: Clarifications in specification of ML-DSA and SLH-DSA

    Posted 02-05-2025 04:56

    P.S. Similar changes apply to section 6.69 SLH-DSA



    ------------------------------
    Best regards,
    Dieter
    ------------------------------



  • 3.  RE: Clarifications in specification of ML-DSA and SLH-DSA

    Posted 02-05-2025 06:49

    THALES GROUP LIMITED DISTRIBUTION to email recipients

     

    those make sense to me

     






  • 4.  RE: Clarifications in specification of ML-DSA and SLH-DSA

    Posted 02-17-2025 01:32
    "If C_AsyncComplete returns an error other than CKR_PENDING, the pValue item of pResult is set to the address passed in the original call to pFunctionName so that it may be freed:

    What is that referring to?
    Is it meant to be the value passed into C_AsyncJoin?
    Or somehow related to the parameters of the original function call?
    It seems that way from the comments in the prose.
    And if so how?

    And why does it talk about freeing them - they may or may not be dynamically allocated?

    How does this interact with C_AsyncJoin and its pData?


    I'm just trying to wrap my head around the interfaces offered here and how they are meant to be used.

    Tim.





  • 5.  RE: Clarifications in specification of ML-DSA and SLH-DSA

    Posted 02-17-2025 11:28

    Hi Tim,

     

    In the case where C_AsyncGetID has not been called, it is referring to the value passed in the original call to pFunctionName (i.e., C_Sign).

    In the case where C_AsyncGetID is called, "the caller should free any memory passed into the original call to pFunctionName". In this case it is referring to the value passed in the call to C_AsyncJoin.

     

    It's there to make it easier to deal with the "variable-length buffer" discussed in section 5.2 where a pointer to a buffer is passed in. Rather than making the client keep track of this pointer, we've put in this bit of "convenience" to callers so that they can manage fewer pieces of data when using the async functions.

     

    Perhaps this would be better?

    If C_AsyncComplete returns an error other than CKR_PENDING, the pValue item of pResult is set to the address passed into C_AsyncJoin as pData, or the address passed into the original call to pFunctionName as the variable-length output buffer, so that it may be freed if dynamically allocated.

     

     

    Sincerely,

    Jonathan

     

     






  • 6.  RE: Clarifications in specification of ML-DSA and SLH-DSA

    Posted 02-17-2025 14:29
    Thanks Jonathan - that updated text would make it clearer and answers my question.

    Tim.






  • 7.  RE: Clarifications in specification of ML-DSA and SLH-DSA

    Posted 02-18-2025 03:25

    I take this as an editorial change for clarification, and will include the wording proposed by Jonathan into working draft 09.



    ------------------------------
    Best regards,
    Dieter
    ------------------------------