On Mon, Dec 8, 2014 at 6:01 PM, roko <[email protected]> wrote: > So, I think padding is now supported, but in my application now I have > this exception: > > Caused by: javax.crypto.ShortBufferException > at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:561) > at sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:464) > at sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:452) > ... 49 more > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: > CKR_BUFFER_TOO_SMALL > at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native > Method) > at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:517) > ... 51 more > > After reading some source code for sun.security.pkcs11.P11Cipher I see that it is not following the PKCS#11 convention for functions returning output in a variable-length buffer. It is tracking the buffered bytes and thus know the exact expected number of bytes that should be returned. A program should normally call C_EncryptUpdate twice, first to get the number of bytes and second call to make the actual encryption. C_EncryptUpdate in SoftHSM is currently not tracking this and will round up to the nearest block size. This is ok according to PKCS#11: "This number may somewhat exceed the precise number of bytes needed, but should not exceed it by a large amount."
We can rewrite the code to calculate the exact number of bytes need when calling C_EncryptUpdate. Just to verify this, are you encrypting data that is not equal to a multiple of the block size (16 bytes)? Does it work better when adjusting it to be equal to a multiple of the block size? // Rickard
_______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
