Do you have some strong opinion if this should go into 0.23.0 or later? We have the encryption part there already so for completeness I would probably like to have also this one in the release unless somebody else would be strongly against.

Sounds OK to add to 0.23.0.

I would like to point out one thing about asymmetric decryption which is affected by this PR. Before applying this PR, it is possible to use only C_DecryptInit and then call C_Decrypt. After applying this PR, another option will be added, namely not to use C_Decrypt, but to use the following sequence of calls: C_DecryptInit -> C_DecryptUpdate -> C_DecryptFinal.

I don't know if there is any application that uses that sequence. If so, it should work without any problems. But the problem arises if the application calls C_DecryptUpdate more than once, i.e. it uses the sequence C_DecryptInit -> C_DecryptUpdate -> C_DecryptUpdate -> C_DecryptFinal. In such a case, asymmetric decryption will fail.

If none of the OpenSC maintainers have reservations about the extension of asymmetric decryption applied in this way, I think it is appropriate to use this PR in OpenSC 0.23.

The C_DecryptUpdate was designed to allow streaming i.e. where it is impractical to buffer the input to make only one call to C_Decrypt. What it sounds like with the C_DecryptInit -> C_DecryptUpdate -> C_DecryptFinal is OpenSC is just accepting the calls to C_DecryptUpdate -> C_DecryptFinal and then calling C_Decrypt.

pkcs11-tool https://github.com/OpenSC/OpenSC/blob/master/src/tools/pkcs11-tool.c#L2607-L2632 will call C_DecryptUpdate multiple times when reading from a file, if the size of the file is greater then in_buffer[1024]. Have you tried a test with a large file?

Is the problem with implementing this on a card?

pkcs11-tool https://github.com/OpenSC/OpenSC/blob/master/src/tools/pkcs11-tool.c#L2607-L2632 will call C_DecryptUpdate multiple times when reading from a file, if the size of the file is greater then in_buffer[1024]. Have you tried a test with a large file?

Is the problem with implementing this on a card?

Already implemented ... symmetric encrypt/decrypt allows the use of streaming (C_EncryptUpdate/C_DecryptUpdate) or "one-time" call (C_Encrypt/C_Decrypt). Relevant tests are performed via github actions (.github/test-oseid.sh).

As for asymmetric decryption, considering that we only implemented RSA decryption and that for a maximum of 4096-bit key, we don't really have a reason to use streaming - there is no need to call C_DecryptUpdate multiple times.

If someone uses "streaming" for RSA decrypt and really uses several C_DecryptUpdate calls, this will not work in the current OpenSC implementation with or without this PR.

I think the discussion in the previous comments is completely unrelated to this PR as they are talking about asymmetric decryption while this implements a symmetric decryption. The streaming input for asymmetric decryption is a corner case, which should be probably opened as a new issue and fixed eventually (but RSA encryption decryption is not much used for anything useful anyway). So unless there are some other comments to the code, I will merge it later this week.