[Opendnssec-user] PKCS11Exception: CKR_DATA_LEN_RANGE using softhsm2

[Rickard Bellgrim]

On Mon, Dec 8, 2014 at 6:01 PM, roko <roko98 at yahoo.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20141208/a41979da/attachment.htm>