On 01/25/2012 12:52 AM, helpcrypto helpcrypto wrote:
Yes, 24 bytes is the length of the key. That key length is different for
different key length. You are supposed to get that length from the encoded
in pkcs #1 format. The underlying decode function should tell you how many
bytes it is returning (assuming it's decoding pkcs #1 data). That is the
value you use.
No it is not a bug. The above convention is only necessary if you need to
find out how much data the call is going to return. Since we know that the
data cannot be more than the modulus size,we can skip directly to option 2
in Section 11.2 of the PKCS 11 spec.
This is quite normal behavior for PKCS #11 applications.
NOTE: In order to implement this properly, you would have to decrypt the
buffer twice, the first time to find the length, the second time to return
the data. You could decrypt once and hold on to the result expecting the
application to come back and ask for the data, but there is no guarrentee
that the next call will ask you to decrypt this same exact data block
(granted it's quite likely, but not guarrenteed), so if you cache, you also
have to verify that encryptedData didn't change between the calls to be
perfectly correct. You could also just return 128 bytes (the maximum
pulDataLen could be), but then thunderbird already knows this, so there's
not point making the call. This is why we skip to option 2 directly.
Understood. FYI: Returning 128 didnt work, at least in my case.
Sorry my bad, I wasn't clear. The double decrypt happens in the case
where you first call C_Decrypt with pData = NULL. In that case you can
return 128 instead of decrypting the data just to get the length. In the
case where C_Decrypt is called with pData != NULL, you need to return
the actual number of bytes coded by the PKCS #1 encoding because you are
actually returning the decrypted data at this point.
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
