RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 [v9]

Sean Mullan mullan at openjdk.org
Fri Jun 7 15:00:13 UTC 2024


On Fri, 7 Jun 2024 13:03:27 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #​11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens —such as NSS— that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #​1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two —or three, for NSS— blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Uniformize paddingObj and Mode.CTS code order
>   
>   When encrypting, the code dealing with paddingObj is placed before the
>   code dealing with Mode.CTS. When decrypting, we the code is in the
>   inverse order. This commit uniformizes the "paddingObj then CTS" order.
>   
>   Also do a minor comment edition.
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

In the release note, it says "To ensure interoperability with SunJCE and Kerberos which uses the CS3 variant (see https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a-add.pdf, a new SunPKCS11 provider configuration attribute named "cipherTextStealingVariant" is introduced and must be set with any of the following values: CS1, CS2 or CS3 to indicate the CTS variant of the underlying PKCS11 library except for NSS as it's known to be CS1."

I didn't understand the interoperability part. If SunJCE and Kerberos use CS3, then how can PKCS11 ensure interoperability if someone sets the variable to CS1 or CS2?

Also, if the property is set to CS2 or CS3, and you are using NSS, is an exception or error thrown?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2155015698



More information about the security-dev mailing list