On 01/24/2012 07:29 AM, helpcrypto helpcrypto wrote:
Ok guys, just to let you know, now its working. (Again, this list
deserves my love)
2 things were happenning:
1-As Rob Relyea (thx) pointed me, i was doing something wrong: My
C_Decrypt function was returning 128 bytes instead of the 24 seems it
should.
Why it should return 24 and not 64/32/16/8...?
AFAIK, 24 its the symmetric key length, but as far as i dont know
which key algorithm or key was used to crypt...how could i know the
length?
Shouldn't Mozilla Thunderbird call with pulDataLen = 24?
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.
2-Mozilla Thunderbird probably has a bug calling this function, and
not following the convention of "invoke first with pulDataLen=0 and
pData=NULL to guess size".
In fact, its invoking with pulDataLen=128 (probably 'cause its using
the same buffer for encrypted/decrypted key?)
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.
According to standard: "Its OK if pEncryptedData and pData point to
the same location", but not their lengths!
Right ulEncryptedDateLen is the length of pEncryptedData. pulDataLen
points to the length of the pData bufffer. You need to know this value
because you can't overshoot it. (If Thunderbird passes in
*pulDataLen=10, and the key length is 24, you need to return the
CKR_BUFFER_TOO_SMALL error, you do not write 24 bytes of data to pData;).
In this case pData is a buffer that is 128 bytes long. There is no
problem writing 24 bytes and then setting *pulDataLen to 24.
This is a bit funky because the spec was defined before anyone thought
about buffer overruns. Hand that been thought of originally, the
functions would have looked like:
C_Decrypt(hSession, pEncryptedData, ulEncryptedDataLen, pData,
ulMaxDataLen, pulDataLen);
Because it wasn't defined this way, the spec specifies the following
semantic:
*pulDataLen = ulMaxDataLen;
C_Decrypt(hSession, pEncryptedData, ulEncryptedDataLen, pData,
ulMaxDataLen, pulDataLen);
In the case of RSA, we know that ulMaxDataLen = ulEncryptedDataLen (the
length of the modulus).
(BTW ulEncryptedDataLen is a stack variable on your calling stack, so
it's impossible for &ulEncryptedDataLen = pulDataLen, go ahead and
change *pulDataLen and compare it to ulEncryptedDataLen to find out why).
Hope that helps you understand what is going on.
Should i file a bug for this?
Nope, I'd just close it invalid;).
Thanks again for your patience and help.
El día 23 de enero de 2012 12:50, Martin Paljak
<mar...@martinpaljak.net> escribió:
On Mon, Jan 23, 2012 at 10:18, helpcrypto helpcrypto
<helpcry...@gmail.com> wrote:
Ill ask again: We do only CKM_RSA_PKCS. Does Mozilla Thundebird
requires other mechanims to work properly?
AFAIK not.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
