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.