RPC: Message-Based Encryption and Signing Functions: pParameter can be "either an input or an output parameter"

[uhhhh2]

According to 5.9.3 C_EncryptMessageBegin:

CK_DECLARE_FUNCTION(CK_RV, C_EncryptMessageBegin)( 
    CK_SESSION_HANDLE hSession,
    CK_VOID_PTR pParameter,
    CK_ULONG ulParameterLen,
    CK_BYTE_PTR pAssociatedData,
    CK_ULONG ulAssociatedDataLen
);

C_EncryptMessageBegin begins a multiple-part message encryption operation. hSession is the session’s handle; pParameter and ulParameterLen specify any mechanism-specific parameters for the message encryption operation; pAssociatedData and ulAssociatedDataLen specify the associated data for an AEAD mechanism.

Typically, pParameter is an initialization vector (IV) or nonce. Depending on the mechanism parameter passed to C_MessageEncryptInit, pParameter may be either an input or an output parameter For example, if the mechanism parameter specifies an IV generator mechanism, the IV generated by the IV generator will be output to the pParameter buffer.

From the above description, pParameter can be either an input or an output.

However, the RPC Server seems to only process the parameter as an input (in between BEGIN_CALL and PROCESS_CALL), not as an output (in between PROCESS_CALL and END_CALL).

Similar issues affect the other message-based encryption and message-based signing functions that involve a pParameter.

The issues only apply to message-based encryption and message-based signing, not message-based decryption and message-based verifying.

According to 5.11.3 C_DecryptMessageBegin:

Unlike the pParameter parameter of C_EncryptMessageBegin, pParameter is always an input parameter.