Proposing a KMAC Mechanism

[simo5]

This PR proposes mechanism for the implementation of KMAC as described in NIST Special Publication 800-185

Fixes #37

[optnfast]

This design supports use of KMAC as a keyed XOF, but doesn't really suit its use as a MAC in an idiomatic way.

I think only a small change is needed to fix this

• permit use with the C_Sign... and C_Verify... APIs
• forbid ulMacLength = 0 with C_Sign... and C_Verify...

[simo5]

This design supports use of KMAC as a keyed XOF, but doesn't really suit its use as a MAC in an idiomatic way.

I think only a small change is needed to fix this

* permit use with the `C_Sign...` and `C_Verify...`  APIs

* forbid `ulMacLength = 0` with `C_Sign...` and `C_Verify...`

So what you are saying is that you want to be able to use KMAC also through the C_sign/C_Verify interface but w/o XOF ?

[optnfast]

Yes, that's right.

The current implementation of KMAC in nShield HSMs functions purely as a MAC, using the native equivalents of the PKCS#11 C_Sign... and C_Verify... APIs. I'd like to be able to expose that functionality via PKCS#11.

The XOF-style interface isn't currently supported for KMAC in nShield (though it could be added, if there is demand for it).

[simo5]

And the signature size output is fully determined by the ulMacLength mechanism parameter in your implementation ? Do you have any limitations on the maximum size of that value ?

[optnfast]

That's right. Currently we require the MAC tag to be between 8 and 4096 bytes.

• The lower limit of 8 is based on a conservative reading of SP800-185.
• The upper limit is (currently) arbitrary and could be expanded a bit if there is demand for more.

[simo5]

That's right. Currently we require the MAC tag to be between 8 and 4096 bytes.

* The lower limit of 8 is based on a conservative reading of SP800-185.

* The upper limit is (currently) arbitrary and could be expanded a bit if there is demand for more.

Just trying to asses what language the spec should use for this field, in the both the XOF and non XOF case. I think I will add langauge that says that implementation may put limits on what is an acceptable value but I want to also provide a "safe" space for interoperability where implentations must support at least a certain range. 8-4096 sound like ok, but I think the spec should mandate something narrower as base line like 32-256 and leave it open to any other value.

[optnfast]

I'd suggest a baseline of 16-256, since 16-byte output from KMAC128 is a very reasonable thing to want. Apart from that, sounds good.