> 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. > 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. > Completely clear by now. Thank you very much for such a great explanation. I own you one more beer guys, Thanks a lot! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
