Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8261355

No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

    XMLWordPrintable

    Details

      Backports

        Description

        When performing an encryption operation with SunPKCS11's Cipher service, the underlying PKCS#11 mechanism may or may not imply padding on the native side. This depends on the algorithm used to initialize the Cipher instance.

        As an example of the previous, when the "AES/ECB/PKCS5Padding" algorithm is used, the underlying mechanism is CKM_AES_ECB and does not involve any padding on the native side. PKCS#11 backends such as the NSS Software Token are expecting, under these circumstances, that all C_EncryptUpdate calls have an input buffer whose length is a multiple of the block-size. Failing to do so results in a CKR_DATA_LEN_RANGE error, as it's happening now.

        The following code snippet reproduces this bug in JDK now:

        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding", p);
        cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(new byte[16], "AES"));
        cipher.update(new byte[1], 0, 1);

        Note: "p" is a SunPKCS11 instance

        ByteBuffer input buffers can be used to trigger this bug as well:

        cipher.update(ByteBuffer.allocate(1), ByteBuffer.allocate(16));

        What we ought to do is, similarly to Cipher decryption operations, holding the data on the Java side and only making C_EncryptUpdate calls with enough bytes to complete a multiple of the block size.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                mbalao Martin Balao
                Reporter:
                mbalao Martin Balao
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: