OASIS PKCS 11 TC

 View Only
Back to discussions
Expand all | Collapse all

Proposed updates to PQ signing based on the final spec.

  • 1.  Proposed updates to PQ signing based on the final spec.

    Posted 08-27-2024 12:55

    1) Add the Following mechanisms:

    #define CKM_ML_DSA_DETERMINISTIC TBD opt
    #define CKM_ML_DSA_PREHASH???????????? TBD opt
    #define CKM_ML_DSA_PREHASH_DETERMINISTIC???? TBD opt

    #define CKM_SLH_DSA_DETERMINISTIC?????????????????????????? TBD opt
    #define CKM_SLH_DSA_PREHASH?????????? TBD opt
    #define CKM_SLH_DSA_PREHASH_DETERMINISTIC?????????? TBD opt

    if you support CKM_SLH_DSA_xxx then CKM_SLH_DSA would be required. The rest are optional. Same with ML_DSA_xxx.??

    Deterministic means the Determinitic version of signing. There is no difference in verification between the standard and deterministic variants.

    Prehash will only be one shot. The application is responsible for the entire hash including the hash oid as specified in the FIPS specs.

    2) optional Params for CKM_ML_DSA_* and CKM_SLH_DSA_* for Signing and verification.

    typedef struct CK_SIGN_ADDITIONAL_CONTEXT { ???????? CK_BYTE_PTR???? pContext; ???????? CK_ULONG      ulContextLen; } CK_SIGN_ADDITONAL_CONTEXT;

    This parameter is optional, and if it's missing ulContextLen will be treated as '0' and pContext will be treated as NULL. The FIPS spec specifies how context is to be process for each signature.


    3) We already decided to rename CKM_FALCON to CKM_FN_DSA. We don't have a spec for it, so I'm not including those changes to FALCON since only the ROUND3 params are specified, and round 3 doesn't specify a pre-hash or?? deterministic varients.


    --------------------------------------

    Comments:

    1) We could optionally extend the optional params and include deterministic as a bool. It the params is not present, deterministic would be false. I decided to make it a mechanism because that allows applications to query if the token even supports deterministic signatures. I could be willing to switch this.

    2) I now remember that we had the deterministic discussion. If this is really a token specific thing (some tokens only generate deterministic signatures because that token does not have a good source of entropy), then we should not add the new deterministic variants.

    3) Do we want to have a CKM_XXX_DSA_PREHASH variant where the token does the hashing? I didn't include it because 1) it seems prehash was for places where the protocol makes it difficult to start the signature before the hashing has to start, and 2) the mechanism would have to carry the HASH somehow (either a and additional parameter or a separate mechanism for each hash).




Related Content