Repository navigation
C_EncapsulateKey does not handle pCipherText == NULL #889
Description
The standard convention in PKCS#11 when dealing with (possibly) variable-length output is to let the user make a call with a NULL output buffer and a buffer length pointer, to which the PKCS#11 implementation should respond by writing the required buffer size to the buffer length pointer and returning CKR_OK. See Section 5.2.
Currently, this case is not handled at all (it looks like it just silently skips trying to write anything to the output buffer, but still performs all the other token operations in the background).
I think this is more or less what needs to be added to C_EncapsulateKey (assumes ML-KEM; the length-determining logic will of course be mechanism-dependent in the general case).
if (pCipherText == NULL_PTR)
{
unsigned long ctLen = ((MLKEMPublicKey*)publicKey)->getOutputLength();
cipher->recyclePublicKey(publicKey);
CryptoFactory::i()->recycleAsymmetricAlgorithm(cipher);
if (ctLen == 0) return CKR_GENERAL_ERROR;
*pulCipherTextLen = ctLen;
return CKR_OK;
}
I know that for ML-KEM this technically doesn't apply given that the output length is fixed anyway, but IMO it'd make sense to allow the caller to follow the standard pattern here so that mechanism-agnostic code can keep working.
Activity
MatthiasValvekens commentedon Jun 21, 2026
@antoinelochet FYI
antoinelochet commentedon Jun 22, 2026
Hello,
You can checkout a fix in the same branch as #888.
I have taken your suggestion and added some other controls and related tests.
Do you want to be added as author on this commit ?
MatthiasValvekens commentedon Jun 22, 2026
That indeed seems to do the trick!
Regarding authorship: if you think my contribution is sufficient to warrant co-authorship, feel free to add a byline to the commit, but I'll let you be the judge of that :).
antoinelochet commentedon Jun 22, 2026
Since I applied your suggestion as-is, it is normal that I give you co-authorship.
You can see it in the commit now :)
MatthiasValvekens commentedon Jun 28, 2026
Fixed in #888, so closing this.