On Mon, 22 Apr 2024 18:31:37 GMT, Francisco Ferrari Bihurriet <fferr...@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 bu ffering 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 data source (`padBuffer` or input... This pull request has now been integrated. Changeset: 4ab7e98c Author: Francisco Ferrari Bihurriet <fferr...@openjdk.org> Committer: Martin Balao <mba...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e Stats: 625 lines in 7 files changed: 533 ins; 28 del; 64 mod 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 Co-authored-by: Francisco Ferrari Bihurriet <fferr...@openjdk.org> Co-authored-by: Martin Balao <mba...@openjdk.org> Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/18898
