Hi Team,
I've been ask to summarize my doubts about the recent proposal I made for
adding KMAC support. My main concern is around the proposed handling of
the signature length, particularly when the mechanism operates in XOF mode.
Here are my points in detail:
-
Arbitrary Signature Length and XOF Mode: As currently specified,
the signature length can be arbitrary. It's either determined by the
ulMacLength parameter in CK_KMAC_PARAMS or, if ulMacLength
is 0, by the pulSignatureLen parameter of the C_Sign function.
When ulMacLength is 0, the mechanism effectively operates in XOF
(Extendable-Output Function) mode. [An XOF is a cryptographic
function that can produce an output of any desired length from a
single input.] While this is a feature of KMAC, having the C_Sign
function determine the output length is a departure from the typical
behavior of signing mechanisms in PKCS#11, where the output length
is generally fixed and defined by the mechanism itself.
-
Alternative: Separate Mechanisms for XOF: To maintain consistency
with the existing PKCS#11 architecture, we could consider defining
separate mechanisms for the XOF functionality, such as
CKM_KMAC128_XOF and CKM_KMAC256_XOF. If we adopt this approach,
the standard CKM_KMAC128 and CKM_KMAC256 mechanisms would
require a non-zero ulMacLength, and a value of 0 would be treated as
an error. This would make the interface clearer and more predictable for
developers familiar with PKCS#11.
-
Challenge with XOF Output Length: If we do introduce separate XOF
mechanisms, the question becomes how to specify the amount of output
to be generated.
-
One option is to require the application to still use the ulMacLength
parameter to specify the number of bytes to extract. However, this
would limit the "extendable" nature of the XOF, as it wouldn't support
scenarios where the required output length is unknown when the
operation is initiated.
-
A more flexible alternative could be to introduce a new function,
perhaps C_Sign_XOF, designed specifically to handle drawing a
variable amount of data from an extendable-output function.
- Final option: No XOF support: of course we could also opt for not
providing any XOF support at this time.
I believe that addressing these points will lead to a more robust and consistent implementation. I'm happy to discuss this further in our next meeting.
Cheers,
Simo.
------------------------------
Simo Sorce
Red Hat
------------------------------