> 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...
Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: Improve test clarity and avoid code duplication Co-authored-by: Francisco Ferrari <fferr...@redhat.com> Co-authored-by: Martin Balao <mba...@redhat.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18898/files - new: https://git.openjdk.org/jdk/pull/18898/files/2c6a3c0f..33a64b2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18898&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18898&range=08-09 Stats: 137 lines in 1 file changed: 56 ins; 69 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/18898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18898/head:pull/18898 PR: https://git.openjdk.org/jdk/pull/18898
