OASIS PKCS 11 TC

For "Hash ML-DSA Signature", we have the following structure defined:

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {

  CK_HEDGE_TYPE      hedgeVariant;

  CK_BYTE_PTR        pContext;

  CK_ULONG           ulContextLen;

  CK_MECHANISM_TYPE  hash   

} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

The "hash" field is used to specify the type of hash or XOF algorithm that was used.  The NIST specs allows any approved hash or XOF function; specifically SHAKE128/SHAKE256.  Unless I missed it, PKCS#11 v3.2 doesn't define any SHAKE128 or SHAKE256 mechanisms that support the hash operation; we only define mechanisms that support the derive operation.  Specifically CKM_SHAKE_128_KEY_DERIVATION and CKM_SHAKE_256_KEY_DERIVATION.  What is our intent here, what CKM_xxx value should be specified so that SHAKE128 or SHAKE 256 can be used?

• Not support SHAKE128 and SHAKE256 with Hash ML-DSA?  This would seem wrong and a short coming of the spec.
• allow these existing SHAKE derivation mechanisms to be used to specify that SHAKE is the pre-hash algorithm that was used?  This could work, but also seems odd/wrong in many ways.
• do we need to define mechanisms for SHAKE128 or SHAKE256 that support hashing (with and/or without variable output length)?  I like this option as it is clearer/cleaner.  But this is obviously a bigger spec change.

Other solutions?

Thanks

Darren

Hi Darren,

good catch. 

I agree that defining mechanisms for SHAKE128 and SHAKE256 is the best option. Defining at least the fixed-length variants SHAKE128(𝑀, 256) and SHAKE256(𝑀, 512) is enough to support FIPS 204 and FIPS 205, and limits the specification changes. We may then add variable-length SHAKE in a future version if needed.

For "Hash ML-DSA Signature", we have the following structure defined:

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {

  CK_HEDGE_TYPE      hedgeVariant;

  CK_BYTE_PTR        pContext;

  CK_ULONG           ulContextLen;

  CK_MECHANISM_TYPE  hash   

} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

The "hash" field is used to specify the type of hash or XOF algorithm that was used.  The NIST specs allows any approved hash or XOF function; specifically SHAKE128/SHAKE256.  Unless I missed it, PKCS#11 v3.2 doesn't define any SHAKE128 or SHAKE256 mechanisms that support the hash operation; we only define mechanisms that support the derive operation.  Specifically CKM_SHAKE_128_KEY_DERIVATION and CKM_SHAKE_256_KEY_DERIVATION.  What is our intent here, what CKM_xxx value should be specified so that SHAKE128 or SHAKE 256 can be used?

• Not support SHAKE128 and SHAKE256 with Hash ML-DSA?  This would seem wrong and a short coming of the spec.
• allow these existing SHAKE derivation mechanisms to be used to specify that SHAKE is the pre-hash algorithm that was used?  This could work, but also seems odd/wrong in many ways.
• do we need to define mechanisms for SHAKE128 or SHAKE256 that support hashing (with and/or without variable output length)?  I like this option as it is clearer/cleaner.  But this is obviously a bigger spec change.

Other solutions?

Thanks

Darren

Hi Darren,

good catch. 

I agree that defining mechanisms for SHAKE128 and SHAKE256 is the best option. Defining at least the fixed-length variants SHAKE128(𝑀, 256) and SHAKE256(𝑀, 512) is enough to support FIPS 204 and FIPS 205, and limits the specification changes. We may then add variable-length SHAKE in a future version if needed.

For "Hash ML-DSA Signature", we have the following structure defined:

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {

  CK_HEDGE_TYPE      hedgeVariant;

  CK_BYTE_PTR        pContext;

  CK_ULONG           ulContextLen;

  CK_MECHANISM_TYPE  hash   

} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

The "hash" field is used to specify the type of hash or XOF algorithm that was used.  The NIST specs allows any approved hash or XOF function; specifically SHAKE128/SHAKE256.  Unless I missed it, PKCS#11 v3.2 doesn't define any SHAKE128 or SHAKE256 mechanisms that support the hash operation; we only define mechanisms that support the derive operation.  Specifically CKM_SHAKE_128_KEY_DERIVATION and CKM_SHAKE_256_KEY_DERIVATION.  What is our intent here, what CKM_xxx value should be specified so that SHAKE128 or SHAKE 256 can be used?

• Not support SHAKE128 and SHAKE256 with Hash ML-DSA?  This would seem wrong and a short coming of the spec.
• allow these existing SHAKE derivation mechanisms to be used to specify that SHAKE is the pre-hash algorithm that was used?  This could work, but also seems odd/wrong in many ways.
• do we need to define mechanisms for SHAKE128 or SHAKE256 that support hashing (with and/or without variable output length)?  I like this option as it is clearer/cleaner.  But this is obviously a bigger spec change.

Other solutions?

Thanks

Darren

Hi Darren,

good catch. 

I agree that defining mechanisms for SHAKE128 and SHAKE256 is the best option. Defining at least the fixed-length variants SHAKE128(𝑀, 256) and SHAKE256(𝑀, 512) is enough to support FIPS 204 and FIPS 205, and limits the specification changes. We may then add variable-length SHAKE in a future version if needed.

For "Hash ML-DSA Signature", we have the following structure defined:

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {

  CK_HEDGE_TYPE      hedgeVariant;

  CK_BYTE_PTR        pContext;

  CK_ULONG           ulContextLen;

  CK_MECHANISM_TYPE  hash   

} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

The "hash" field is used to specify the type of hash or XOF algorithm that was used.  The NIST specs allows any approved hash or XOF function; specifically SHAKE128/SHAKE256.  Unless I missed it, PKCS#11 v3.2 doesn't define any SHAKE128 or SHAKE256 mechanisms that support the hash operation; we only define mechanisms that support the derive operation.  Specifically CKM_SHAKE_128_KEY_DERIVATION and CKM_SHAKE_256_KEY_DERIVATION.  What is our intent here, what CKM_xxx value should be specified so that SHAKE128 or SHAKE 256 can be used?

• Not support SHAKE128 and SHAKE256 with Hash ML-DSA?  This would seem wrong and a short coming of the spec.
• allow these existing SHAKE derivation mechanisms to be used to specify that SHAKE is the pre-hash algorithm that was used?  This could work, but also seems odd/wrong in many ways.
• do we need to define mechanisms for SHAKE128 or SHAKE256 that support hashing (with and/or without variable output length)?  I like this option as it is clearer/cleaner.  But this is obviously a bigger spec change.

Other solutions?

Thanks

Darren

Hi Darren,

good catch. 

I agree that defining mechanisms for SHAKE128 and SHAKE256 is the best option. Defining at least the fixed-length variants SHAKE128(𝑀, 256) and SHAKE256(𝑀, 512) is enough to support FIPS 204 and FIPS 205, and limits the specification changes. We may then add variable-length SHAKE in a future version if needed.

For "Hash ML-DSA Signature", we have the following structure defined:

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {

  CK_HEDGE_TYPE      hedgeVariant;

  CK_BYTE_PTR        pContext;

  CK_ULONG           ulContextLen;

  CK_MECHANISM_TYPE  hash   

} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

The "hash" field is used to specify the type of hash or XOF algorithm that was used.  The NIST specs allows any approved hash or XOF function; specifically SHAKE128/SHAKE256.  Unless I missed it, PKCS#11 v3.2 doesn't define any SHAKE128 or SHAKE256 mechanisms that support the hash operation; we only define mechanisms that support the derive operation.  Specifically CKM_SHAKE_128_KEY_DERIVATION and CKM_SHAKE_256_KEY_DERIVATION.  What is our intent here, what CKM_xxx value should be specified so that SHAKE128 or SHAKE 256 can be used?

• Not support SHAKE128 and SHAKE256 with Hash ML-DSA?  This would seem wrong and a short coming of the spec.
• allow these existing SHAKE derivation mechanisms to be used to specify that SHAKE is the pre-hash algorithm that was used?  This could work, but also seems odd/wrong in many ways.
• do we need to define mechanisms for SHAKE128 or SHAKE256 that support hashing (with and/or without variable output length)?  I like this option as it is clearer/cleaner.  But this is obviously a bigger spec change.

Other solutions?

Thanks

Darren

Hi Darren,

good catch. 

I agree that defining mechanisms for SHAKE128 and SHAKE256 is the best option. Defining at least the fixed-length variants SHAKE128(𝑀, 256) and SHAKE256(𝑀, 512) is enough to support FIPS 204 and FIPS 205, and limits the specification changes. We may then add variable-length SHAKE in a future version if needed.

For "Hash ML-DSA Signature", we have the following structure defined:

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {

  CK_HEDGE_TYPE      hedgeVariant;

  CK_BYTE_PTR        pContext;

  CK_ULONG           ulContextLen;

  CK_MECHANISM_TYPE  hash   

} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

The "hash" field is used to specify the type of hash or XOF algorithm that was used.  The NIST specs allows any approved hash or XOF function; specifically SHAKE128/SHAKE256.  Unless I missed it, PKCS#11 v3.2 doesn't define any SHAKE128 or SHAKE256 mechanisms that support the hash operation; we only define mechanisms that support the derive operation.  Specifically CKM_SHAKE_128_KEY_DERIVATION and CKM_SHAKE_256_KEY_DERIVATION.  What is our intent here, what CKM_xxx value should be specified so that SHAKE128 or SHAKE 256 can be used?

• Not support SHAKE128 and SHAKE256 with Hash ML-DSA?  This would seem wrong and a short coming of the spec.
• allow these existing SHAKE derivation mechanisms to be used to specify that SHAKE is the pre-hash algorithm that was used?  This could work, but also seems odd/wrong in many ways.
• do we need to define mechanisms for SHAKE128 or SHAKE256 that support hashing (with and/or without variable output length)?  I like this option as it is clearer/cleaner.  But this is obviously a bigger spec change.

Other solutions?

Thanks

Darren

Hi,

Hopefully, this isn't too late for the discussion on ML-DSA (Draft 08/09/10), specifically 6.67.6 HashML-DSA Signature (a.k.a FIPS 204 §5.4 prehash) and 6.67.7 HashML-DSA Signature with hashing, which I believe is not part of FIPS 204.

1. ML-DSA (Draft 08/09/10) – 6.67.6 HashML-DSA Signature (a.k.a. FIPS 204 §5.4 Prehash), Regarding SHAKE128 and SHAKE256

In FIPS 204, Algorithm 4, lines 17–20:

17: case SHAKE128:  
18: OID ← 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0B  ▷ 2.16.840.1.101.3.4.2.11  
19: PH𝑀 ← SHAKE128(𝑀, 256)  

20: case …  

Q: SHAKE256 in FIPS 204: FIPS 204 does not provide pseudocode for SHAKE256.

• 1. Can we safely assume it should be PH𝑀 ← SHAKE256(𝑀, 512)?
  2. Does FIPS 204 only require fixed-length SHAKE, such as SHAKE128(M, 256) and SHAKE256(M, 512)?
  3. If variable-length SHAKE is allowed, should we introduce a new field  CK_HASH_SIGN_ADDITIONAL_CONTEXT to specify the output length dynamically?

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {  
    CK_HEDGE_TYPE      hedgeVariant;  
    CK_BYTE_PTR        pContext;  
    CK_ULONG           ulContextLen;  
    CK_MECHANISM_TYPE  hash;  
    CK_ULONG           ulShakeOutputLen;  
} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

2. Understanding 6.67.7 HashML-DSA Signature with Hashing (Not Part of FIPS 204)

It is unclear how the 6.67.7 HashML-DSA Signature with Hashing differs from the 6.67.6 HashML-DSA Signature (Prehash, FIPS 204 §5.4).

Mechanism: CKM_HASH_ML_DSA_<hash>

My understanding about this is as follows:

1. Hashes the Original Message (M) First

Unlike prehash ML-DSA, which signs a processed message M', this mode directly hashes the original message M using the specified hash function. <hash> (e.g., SHA-256, SHA3-256).

2. Uses the Hash Output for ML-DSA Sign/Verify (Pure Sign/Verify, Not PH Sign/Verify)

• • The resulting Hₘ = HASH<hash>(M) is passed to ML-DSA-SIGN / VERIFY.
  • For verification, the verifier hashes M the same way and checks it against the signature.
  • Important: Inside ML-DSA-SIGN/VERIFY, the hashed message Hₘ must be processed before being fed into FIPS 204 Algorithm 7 & 8:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><msup><mi>M</mi><mo mathvariant="normal" lspace="0em" rspace="0em">′</mo></msup><mo>←</mo><mtext>BytesToBits</mtext><mo stretchy="false">(</mo><mtext>IntegerToBytes</mtext><mo stretchy="false">(</mo><mn>0</mn><mo separator="true">,</mo><mn>1</mn><mo stretchy="false">)</mo><mo>∥</mo><mtext>IntegerToBytes</mtext><mo stretchy="false">(</mo><mi mathvariant="normal">∣</mi><mi>c</mi><mi>t</mi><mi>x</mi><mi mathvariant="normal">∣</mi><mo separator="true">,</mo><mn>1</mn><mo stretchy="false">)</mo><mo>∥</mo><mi>c</mi><mi>t</mi><mi>x</mi><mo stretchy="false">)</mo><mo>∥</mo><mi>H</mi><mi>m</mi></mrow><annotation encoding="application/x-tex">M' \gets \text{BytesToBits}(\text{IntegerToBytes}(0, 1) \parallel \text{IntegerToBytes}(|ctx|, 1) \parallel ctx) \parallel Hm</annotation></semantics></math>

The PKCS#11 v3.2 draft (08/09/10) describes CKM_HASH_ML_DSA_<hash> as:

"A mechanism for single- and multiple-part signatures and verification for pre-hash ML-DSA signatures as defined in FIPS 204 §5.4, Algorithm 4 (HashML-DSA.Sign) and Algorithm 5 (HashML-DSA.Verify). This mechanism computes the entire HashML-DSA specification, including hashing on-token. The data passed in is the original message M."

However, this description (from my understanding) suggests a double hashing process:

1. First, the input message M is hashed using <hash>: <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><msub><mi>H</mi><mi>m</mi></msub><mo>=</mo><mtext>HASH</mtext><mo><</mo><mi>h</mi><mi>a</mi><mi>s</mi><mi>h</mi><mo>></mo><mo stretchy="false">(</mo><mi>M</mi><mo stretchy="false">)</mo></mrow><annotation encoding="application/x-tex">Hₘ = \text{HASH}<hash>(M)</annotation></semantics></math>
2. Then, Hₘ is passed to Algorithm 4 (HashML-DSA.Sign) and Algorithm 5 (HashML-DSA.Verify).
3. Inside HashML-DSA.Sign/Verify, Hₘ undergoes an additional hash operation: <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><mi>P</mi><msub><mi>H</mi><mi>m</mi></msub><mo>←</mo><mtext>HASH</mtext><mo><</mo><mi>h</mi><mi>a</mi><mi>s</mi><mi>h</mi><mo>></mo><mo stretchy="false">(</mo><msub><mi>H</mi><mi>m</mi></msub><mo stretchy="false">)</mo><mspace width="1em"></mspace><mi mathvariant="normal">/</mi><mi mathvariant="normal">/</mi><mtext>Double hash using the same </mtext><mo><</mo><mi>h</mi><mi>a</mi><mi>s</mi><mi>h</mi><mo>></mo></mrow><annotation encoding="application/x-tex">PHₘ \gets \text{HASH}<hash>(Hₘ) \quad // \text{Double hash using the same } <hash></annotation></semantics></math>
4. The processed message M' is then constructed as: <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><msup><mi>M</mi><mo mathvariant="normal" lspace="0em" rspace="0em">′</mo></msup><mo>←</mo><mtext>BytesToBits</mtext><mo stretchy="false">(</mo><mtext>IntegerToBytes</mtext><mo stretchy="false">(</mo><mn>1</mn><mo separator="true">,</mo><mn>1</mn><mo stretchy="false">)</mo><mo>∥</mo><mtext>IntegerToBytes</mtext><mo stretchy="false">(</mo><mi mathvariant="normal">∣</mi><mi>c</mi><mi>t</mi><mi>x</mi><mi mathvariant="normal">∣</mi><mo separator="true">,</mo><mn>1</mn><mo stretchy="false">)</mo><mo>∥</mo><mi>c</mi><mi>t</mi><mi>x</mi><mo>∥</mo><mi>O</mi><mi>I</mi><mi>D</mi><mo>∥</mo><mi>P</mi><msub><mi>H</mi><mi>m</mi></msub><mo stretchy="false">)</mo></mrow><annotation encoding="application/x-tex">M' \gets \text{BytesToBits}(\text{IntegerToBytes}(1, 1) \parallel \text{IntegerToBytes}(|ctx|, 1) \parallel ctx \parallel OID \parallel PHₘ)</annotation></semantics></math>
5. Finally, M' is fed into FIPS 204 Algorithm 7 & 8 for signing and verification.

Q1: Key Questions & Next Steps?

• 1. Is the intention of CKM_HASH_ML_DSA_<hash> indeed a double hashing process?
  2. Should PKCS#11 explicitly differentiate this from standard ML-DSA prehash (FIPS 204 §5.4)?
  3. Does this behavior align with real-world FIPS 204 test cases (FIPS 204 approved)?

Q2: Key Considerations for SHAKE128/SHAKE256:

1. 1. If <hash> is SHAKE128 or SHAKE256, what should the output length (outputLen) be?
   2. Should SHAKE output length be fixed or variable?
   3. How do we specify this variable length within the mechanism?

Thanks, Hui

Hi Darren,

good catch. 

I agree that defining mechanisms for SHAKE128 and SHAKE256 is the best option. Defining at least the fixed-length variants SHAKE128(𝑀, 256) and SHAKE256(𝑀, 512) is enough to support FIPS 204 and FIPS 205, and limits the specification changes. We may then add variable-length SHAKE in a future version if needed.

For "Hash ML-DSA Signature", we have the following structure defined:

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {

  CK_HEDGE_TYPE      hedgeVariant;

  CK_BYTE_PTR        pContext;

  CK_ULONG           ulContextLen;

  CK_MECHANISM_TYPE  hash   

} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

The "hash" field is used to specify the type of hash or XOF algorithm that was used.  The NIST specs allows any approved hash or XOF function; specifically SHAKE128/SHAKE256.  Unless I missed it, PKCS#11 v3.2 doesn't define any SHAKE128 or SHAKE256 mechanisms that support the hash operation; we only define mechanisms that support the derive operation.  Specifically CKM_SHAKE_128_KEY_DERIVATION and CKM_SHAKE_256_KEY_DERIVATION.  What is our intent here, what CKM_xxx value should be specified so that SHAKE128 or SHAKE 256 can be used?

• Not support SHAKE128 and SHAKE256 with Hash ML-DSA?  This would seem wrong and a short coming of the spec.
• allow these existing SHAKE derivation mechanisms to be used to specify that SHAKE is the pre-hash algorithm that was used?  This could work, but also seems odd/wrong in many ways.
• do we need to define mechanisms for SHAKE128 or SHAKE256 that support hashing (with and/or without variable output length)?  I like this option as it is clearer/cleaner.  But this is obviously a bigger spec change.

Other solutions?

Thanks

Darren

Hi,
Please disregard Message 7, which I posted earlier, as it contains a replacement for my math equation. Instead, please refer to this one. My apologies for the confusion !!!

Hopefully, this isn't too late for the discussion on ML-DSA (Draft 08/09/10), specifically 6.67.6 HashML-DSA Signature (a.k.a FIPS 204 §5.4 prehash) and 6.67.7 HashML-DSA Signature with hashing, which I believe is not part of FIPS 204.

1. ML-DSA (Draft 08/09/10) – 6.67.6 HashML-DSA Signature (a.k.a. FIPS 204 §5.4 Prehash), Regarding SHAKE128 and SHAKE256

In FIPS 204, Algorithm 4, lines 17–20:

17: case SHAKE128:  
18: OID ← 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0B  ▷ 2.16.840.1.101.3.4.2.11  
19: PH𝑀 ← SHAKE128(𝑀, 256)  

20: case …  

Q: SHAKE256 in FIPS 204: FIPS 204 does not provide pseudocode for SHAKE256.

• 1. Can we safely assume it should be PH𝑀 ← SHAKE256(𝑀, 512)?
  2. Does FIPS 204 only require fixed-length SHAKE, such as SHAKE128(M, 256) and SHAKE256(M, 512)?
  3. If variable-length SHAKE is allowed, should we introduce a new field  CK_HASH_SIGN_ADDITIONAL_CONTEXT to specify the output length dynamically?

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {  
    CK_HEDGE_TYPE      hedgeVariant;  
    CK_BYTE_PTR        pContext;  
    CK_ULONG           ulContextLen;  
    CK_MECHANISM_TYPE  hash;  
    CK_ULONG           ulShakeOutputLen;  
} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

2. Understanding 6.67.7 HashML-DSA Signature with Hashing (Not Part of FIPS 204)

It is unclear how the 6.67.7 HashML-DSA Signature with Hashing differs from the 6.67.6 HashML-DSA Signature (Prehash, FIPS 204 §5.4).

Mechanism: CKM_HASH_ML_DSA_<hash>

My understanding about this is as follows:

1. Hashes the Original Message (M) First

Unlike prehash ML-DSA, which signs a processed message M', this mode directly hashes the original message M using the specified hash function. <hash> (e.g., SHA-256, SHA3-256).

2. Uses the Hash Output for ML-DSA Sign/Verify (Pure Sign/Verify, Not PH Sign/Verify)

• • The resulting Hₘ = HASH<hash>(M) is passed to ML-DSA-SIGN / VERIFY.
  • For verification, the verifier hashes M the same way and checks it against the signature.
  • Important: Inside ML-DSA-SIGN/VERIFY, the hashed message Hₘ must be processed before being fed into FIPS 204 Algorithm 7 & 8:

M' ← BytesToBits(IntegerToBytes(0, 1) || IntegerToBytes(|ctx|, 1) || ctx) || Hm

The PKCS#11 v3.2 draft (08/09/10) describes CKM_HASH_ML_DSA_<hash> as:

"A mechanism for single- and multiple-part signatures and verification for pre-hash ML-DSA signatures as defined in FIPS 204 §5.4, Algorithm 4 (HashML-DSA.Sign) and Algorithm 5 (HashML-DSA.Verify). This mechanism computes the entire HashML-DSA specification, including hashing on-token. The data passed in is the original message M."

However, this description (from my understanding) suggests a double hashing process:

1. First, the input message M is hashed using <hash>: Hm = HASH<hash>(M)
2. Then, Hₘ is passed to Algorithm 4 (HashML-DSA.Sign) and Algorithm 5 (HashML-DSA.Verify).
3. Inside HashML-DSA.Sign/Verify, Hₘ undergoes an additional hash operation: PHm ← HASH<hash>(Hm)
4. The processed message M' is then constructed as:
   M' ← BytesToBits(IntegerToBytes(1, 1) || IntegerToBytes(|ctx|, 1) || ctx || OID || PHm)
5. Finally, M' is fed into FIPS 204 Algorithm 7 & 8 for signing and verification.

Q1: Key Questions & Next Steps?

• 1. Is the intention  CKM_HASH_ML_DSA_<hash> indeed a double hashing process?
  2. Should PKCS#11 explicitly differentiate this from standard ML-DSA prehash (FIPS 204 §5.4)?
  3. Does this behavior align with real-world FIPS 204 test cases (FIPS 204 approved)?

Q2: Key Considerations for SHAKE128/SHAKE256:

1. 1. If <hash> is SHAKE128 or SHAKE256, what should the output length (outputLen) be?
   2. Should SHAKE output length be fixed or variable?
   3. How do we specify this variable length within the mechanism?

Thanks,
Hui

Hi,

Hopefully, this isn't too late for the discussion on ML-DSA (Draft 08/09/10), specifically 6.67.6 HashML-DSA Signature (a.k.a FIPS 204 §5.4 prehash) and 6.67.7 HashML-DSA Signature with hashing, which I believe is not part of FIPS 204.

1. ML-DSA (Draft 08/09/10) – 6.67.6 HashML-DSA Signature (a.k.a. FIPS 204 §5.4 Prehash), Regarding SHAKE128 and SHAKE256

In FIPS 204, Algorithm 4, lines 17–20:

17: case SHAKE128:  
18: OID ← 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0B  ▷ 2.16.840.1.101.3.4.2.11  
19: PH𝑀 ← SHAKE128(𝑀, 256)  

20: case …  

Q: SHAKE256 in FIPS 204: FIPS 204 does not provide pseudocode for SHAKE256.

• 1. Can we safely assume it should be PH𝑀 ← SHAKE256(𝑀, 512)?
  2. Does FIPS 204 only require fixed-length SHAKE, such as SHAKE128(M, 256) and SHAKE256(M, 512)?
  3. If variable-length SHAKE is allowed, should we introduce a new field  CK_HASH_SIGN_ADDITIONAL_CONTEXT to specify the output length dynamically?

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {  
    CK_HEDGE_TYPE      hedgeVariant;  
    CK_BYTE_PTR        pContext;  
    CK_ULONG           ulContextLen;  
    CK_MECHANISM_TYPE  hash;  
    CK_ULONG           ulShakeOutputLen;  
} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

2. Understanding 6.67.7 HashML-DSA Signature with Hashing (Not Part of FIPS 204)

It is unclear how the 6.67.7 HashML-DSA Signature with Hashing differs from the 6.67.6 HashML-DSA Signature (Prehash, FIPS 204 §5.4).

Mechanism: CKM_HASH_ML_DSA_<hash>

My understanding about this is as follows:

1. Hashes the Original Message (M) First

Unlike prehash ML-DSA, which signs a processed message M', this mode directly hashes the original message M using the specified hash function. <hash> (e.g., SHA-256, SHA3-256).

2. Uses the Hash Output for ML-DSA Sign/Verify (Pure Sign/Verify, Not PH Sign/Verify)

• • The resulting Hₘ = HASH<hash>(M) is passed to ML-DSA-SIGN / VERIFY.
  • For verification, the verifier hashes M the same way and checks it against the signature.
  • Important: Inside ML-DSA-SIGN/VERIFY, the hashed message Hₘ must be processed before being fed into FIPS 204 Algorithm 7 & 8:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><msup><mi>M</mi><mo mathvariant="normal" lspace="0em" rspace="0em">′</mo></msup><mo>←</mo><mtext>BytesToBits</mtext><mo stretchy="false">(</mo><mtext>IntegerToBytes</mtext><mo stretchy="false">(</mo><mn>0</mn><mo separator="true">,</mo><mn>1</mn><mo stretchy="false">)</mo><mo>∥</mo><mtext>IntegerToBytes</mtext><mo stretchy="false">(</mo><mi mathvariant="normal">∣</mi><mi>c</mi><mi>t</mi><mi>x</mi><mi mathvariant="normal">∣</mi><mo separator="true">,</mo><mn>1</mn><mo stretchy="false">)</mo><mo>∥</mo><mi>c</mi><mi>t</mi><mi>x</mi><mo stretchy="false">)</mo><mo>∥</mo><mi>H</mi><mi>m</mi></mrow><annotation encoding="application/x-tex">M' \gets \text{BytesToBits}(\text{IntegerToBytes}(0, 1) \parallel \text{IntegerToBytes}(|ctx|, 1) \parallel ctx) \parallel Hm</annotation></semantics></math>

The PKCS#11 v3.2 draft (08/09/10) describes CKM_HASH_ML_DSA_<hash> as:

"A mechanism for single- and multiple-part signatures and verification for pre-hash ML-DSA signatures as defined in FIPS 204 §5.4, Algorithm 4 (HashML-DSA.Sign) and Algorithm 5 (HashML-DSA.Verify). This mechanism computes the entire HashML-DSA specification, including hashing on-token. The data passed in is the original message M."

However, this description (from my understanding) suggests a double hashing process:

1. First, the input message M is hashed using <hash>: <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><msub><mi>H</mi><mi>m</mi></msub><mo>=</mo><mtext>HASH</mtext><mo><</mo><mi>h</mi><mi>a</mi><mi>s</mi><mi>h</mi><mo>></mo><mo stretchy="false">(</mo><mi>M</mi><mo stretchy="false">)</mo></mrow><annotation encoding="application/x-tex">Hₘ = \text{HASH}<hash>(M)</annotation></semantics></math>
2. Then, Hₘ is passed to Algorithm 4 (HashML-DSA.Sign) and Algorithm 5 (HashML-DSA.Verify).
3. Inside HashML-DSA.Sign/Verify, Hₘ undergoes an additional hash operation: <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><mi>P</mi><msub><mi>H</mi><mi>m</mi></msub><mo>←</mo><mtext>HASH</mtext><mo><</mo><mi>h</mi><mi>a</mi><mi>s</mi><mi>h</mi><mo>></mo><mo stretchy="false">(</mo><msub><mi>H</mi><mi>m</mi></msub><mo stretchy="false">)</mo><mspace width="1em"></mspace><mi mathvariant="normal">/</mi><mi mathvariant="normal">/</mi><mtext>Double hash using the same </mtext><mo><</mo><mi>h</mi><mi>a</mi><mi>s</mi><mi>h</mi><mo>></mo></mrow><annotation encoding="application/x-tex">PHₘ \gets \text{HASH}<hash>(Hₘ) \quad // \text{Double hash using the same } <hash></annotation></semantics></math>
4. The processed message M' is then constructed as: <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><msup><mi>M</mi><mo mathvariant="normal" lspace="0em" rspace="0em">′</mo></msup><mo>←</mo><mtext>BytesToBits</mtext><mo stretchy="false">(</mo><mtext>IntegerToBytes</mtext><mo stretchy="false">(</mo><mn>1</mn><mo separator="true">,</mo><mn>1</mn><mo stretchy="false">)</mo><mo>∥</mo><mtext>IntegerToBytes</mtext><mo stretchy="false">(</mo><mi mathvariant="normal">∣</mi><mi>c</mi><mi>t</mi><mi>x</mi><mi mathvariant="normal">∣</mi><mo separator="true">,</mo><mn>1</mn><mo stretchy="false">)</mo><mo>∥</mo><mi>c</mi><mi>t</mi><mi>x</mi><mo>∥</mo><mi>O</mi><mi>I</mi><mi>D</mi><mo>∥</mo><mi>P</mi><msub><mi>H</mi><mi>m</mi></msub><mo stretchy="false">)</mo></mrow><annotation encoding="application/x-tex">M' \gets \text{BytesToBits}(\text{IntegerToBytes}(1, 1) \parallel \text{IntegerToBytes}(|ctx|, 1) \parallel ctx \parallel OID \parallel PHₘ)</annotation></semantics></math>
5. Finally, M' is fed into FIPS 204 Algorithm 7 & 8 for signing and verification.

Q1: Key Questions & Next Steps?

• 1. Is the intention of CKM_HASH_ML_DSA_<hash> indeed a double hashing process?
  2. Should PKCS#11 explicitly differentiate this from standard ML-DSA prehash (FIPS 204 §5.4)?
  3. Does this behavior align with real-world FIPS 204 test cases (FIPS 204 approved)?

Q2: Key Considerations for SHAKE128/SHAKE256:

1. 1. If <hash> is SHAKE128 or SHAKE256, what should the output length (outputLen) be?
   2. Should SHAKE output length be fixed or variable?
   3. How do we specify this variable length within the mechanism?

Thanks, Hui

Hi Darren,

good catch. 

I agree that defining mechanisms for SHAKE128 and SHAKE256 is the best option. Defining at least the fixed-length variants SHAKE128(𝑀, 256) and SHAKE256(𝑀, 512) is enough to support FIPS 204 and FIPS 205, and limits the specification changes. We may then add variable-length SHAKE in a future version if needed.

For "Hash ML-DSA Signature", we have the following structure defined:

typedef struct CK_HASH_SIGN_ADDITIONAL_CONTEXT {

  CK_HEDGE_TYPE      hedgeVariant;

  CK_BYTE_PTR        pContext;

  CK_ULONG           ulContextLen;

  CK_MECHANISM_TYPE  hash   

} CK_HASH_SIGN_ADDITIONAL_CONTEXT;

The "hash" field is used to specify the type of hash or XOF algorithm that was used.  The NIST specs allows any approved hash or XOF function; specifically SHAKE128/SHAKE256.  Unless I missed it, PKCS#11 v3.2 doesn't define any SHAKE128 or SHAKE256 mechanisms that support the hash operation; we only define mechanisms that support the derive operation.  Specifically CKM_SHAKE_128_KEY_DERIVATION and CKM_SHAKE_256_KEY_DERIVATION.  What is our intent here, what CKM_xxx value should be specified so that SHAKE128 or SHAKE 256 can be used?

• Not support SHAKE128 and SHAKE256 with Hash ML-DSA?  This would seem wrong and a short coming of the spec.
• allow these existing SHAKE derivation mechanisms to be used to specify that SHAKE is the pre-hash algorithm that was used?  This could work, but also seems odd/wrong in many ways.
• do we need to define mechanisms for SHAKE128 or SHAKE256 that support hashing (with and/or without variable output length)?  I like this option as it is clearer/cleaner.  But this is obviously a bigger spec change.

Other solutions?

Thanks

Darren