Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
Robert Relyea rrel...@redhat.com wrote: 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. AFAIK first call C_Decrypt with pData=NULL and pulDataLen=0 should return the decrypt bytes length (X). Then, second call should have pData!=NULL and pulDataLen=y. if yX -CKR_BUFFER_TOO_SMALL Returning 128 doesnt work (and shouldnt), cause the decrypted data is 24 (always?) bytes length Anyhow, i now return the correct size (24) and dont trust on C_Decrypt input pulDataLen. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
On 01/26/2012 12:04 AM, helpcrypto helpcrypto wrote: Robert Relyearrel...@redhat.com wrote: 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. AFAIK first call C_Decrypt with pData=NULL and pulDataLen=0 should return the decrypt bytes length (X). Then, second call should have pData!=NULL and pulDataLen=y. if yX -CKR_BUFFER_TOO_SMALL Returning 128 doesnt work (and shouldnt), cause the decrypted data is 24 (always?) bytes length In the first call you need to return a value at least big enough to hold the decrypted data. 128 bytes (size of encrypted data) is big enough for RSA. This isn't ideal, however. You keep saying the data is 24 bytes, but that's not a given, it's only true in the case you were talking. If you receive a different type of key it could be a different size. Even if I know the key type is RC5, for instance, I still don't know the key length. That is encoded in the PKCS #1. In order to get that you need to decrypt the block. That is why I was saying using the first call/second call method could lead to needing to double decrypt (once to find the length and once to return the data). Anyhow, i now return the correct size (24) and dont trust on C_Decrypt input pulDataLen. err, are you hard coding the size at 24. That is not what I said to do. You function that use used to decrypt your PKCS #1 data returns a data length somewhere. It has to or the function is incomplete (it's not really processing the PKCS #1 data). That data length is what you need to return. bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
In the first call you need to return a value at least big enough to hold the decrypted data. 128 bytes (size of encrypted data) is big enough for RSA. This isn't ideal, however. You keep saying the data is 24 bytes, but that's not a given, it's only true in the case you were talking. If you receive a different type of key it could be a different size. Even if I know the key type is RC5, for instance, I still don't know the key length. That is encoded in the PKCS #1. In order to get that you need to decrypt the block. That is why I was saying using the first call/second call method could lead to needing to double decrypt (once to find the length and once to return the data). This is what im doing, dont worry. err, are you hard coding the size at 24. That is not what I said to do. You function that use used to decrypt your PKCS #1 data returns a data length somewhere. It has to or the function is incomplete (it's not really processing the PKCS #1 data). That data length is what you need to return. Not hardcoding. That would be a nightmare. I do it as you said some mails ago: twice. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
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
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
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
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
Le mardi 24 janvier 2012 16:29:05 UTC+1, helpcrypto helpcrypto a écrit : 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...? The call to the PKCS#11 library specifies CKM_RSA_PKCS as the mechanism. So the library is expected to handle PKCS1v1_5 padding rules. The library doesn't have to know in advance the size of the key, it only needs to check the padding, remove it, and return the data that was really encrypted. The caller (Thunderbird) doesn't need to tell the library: I need to get 16/24/32/whatever bytes. 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. Re-read the section 11.2 of PKCS#11. What you describe is only 1 of the 2 acceptable ways (in fact, in this way, nothing is imposed on *pulDataLen). Thunderbird uses the second way, which is described. In fact, its invoking with pulDataLen=128 (probably 'cause its using the same buffer for encrypted/decrypted key?) According to standard: Its OK if pEncryptedData and pData point to the same location, but not their lengths! Nothing is imposed on pulDataLen. pData and pEncryptedData can be the same, it is up to the library to support it. Thunderbird expects at most 128 bytes, maybe because the private key is an RSA one of 1024 bits? Anyway, if the library detects that *pulDataLen is not large enough, CKR_ENCRYPTED_DATA_LEN_RANGE can be returned. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
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? 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?) According to standard: Its OK if pEncryptedData and pData point to the same location, but not their lengths! Should i file a bug for this? 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
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
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
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
Hi again rob/all, thx for your answer. This appears to be your problem. I have know idea what library you are using for your primitives (presumably openssl) Yeah, Openssl , but it clearly is not decrypting the key with RSA_PKCS1_PADDING. The expected result should be something like 24-16 bytes, which should be the symmetric key you encrypted with. So: Its is correct Thunderbird to invoke once to C_Decrypt with 128 bytes of data, and i should return a symmetric key to decrypt the email? Did Thunderbird crypted the key with my public RSA key? how can i know if 24 or 16? does any difference if Thunderbird used 512/1024/2048 ? Which one used? The code makes me wonder what you are trying to do, however. It looks more like a 'simulated' smart card. Indeed, its not a real crypto card, only a not-so-smart one. I presume that d2i_RSAPrivateKey takes the actual private key that matches the public key used by S/MIME. Presumably the data is stored somewhere and you aren't just 'regenerating a new key'. could you explain what 'regenerating a new key' means? The software is working perfectly for signning, which is quite similar If you were using a smart card, I would have expected a card specific APDU call which passes the encrypted data to the card and got the decrypted data back. No Sir. This is not a cryptographic card. The card only stores the cert+keys, but operations are done in memory. (...do lemmonade) It appears to be a bug in your code at this point. If you are using the correct key, and you are using RSA_PKCS1_PADDING, your RSA_private_decrypt should work. As im using an openssl function, i dont see the possible error in here. Still...is Thunderbird doing the following?: -Mozilla should ask for mechanisms (does) -Mozilla should see the card dont implement any symmetric mechanism (so, must handle the symmetric part of this by his own) (does?) -Mozilla should crypt/decrypt the symmetric key using my public RSA, only to do a C_Decrypt call (does??) Must we code C_UnWrapKey function and so to Decrypt, cause Thunderbird doesnt like our PKCS#11 just does CKM_RSA_PKCS? Thunderbird is perfectly happy with CKM_RSA_PKCS. Ill ask again: We do only CKM_RSA_PKCS. Does Mozilla Thundebird requires other mechanims to work properly? Thanks again for your time and help, im going to review the code one more time. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
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
Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
Hello guys! Sorry if already asked on the list, but i cant find a similar issue.(Maybe i have to improve my find skills) We are developing a PKCS#11 library for our smartcard, actually working great on win, Linux and osx. (No, its not based on OpenSC, although IMHO it should) Yesterday we started working on the en/decryption of emails on Thunderbird. As emails are encrypted with the public cert of destination address Thunderbird does all encryption, and messages arrive OK. We have installed a cert on Thunderbird/nss and they also are decrypted. The problem, hence the mail, comes when the private key is on our smartcard, not on the Thunderbird. We will like to know how can we solve it, if possible, or if its a bug...whatever. Our PKCS#11 library has the following mechanisms: -CKM_RSA_PKCS (1024). This mechanisms has flags CKF_SIGN | CKF_DECRYPT -CKF_GENERATE_KEY_PAIR with CKM_RSA_PKCS_KEY_PAIR_GEN flag AFAIK, emails are encrypted with a symmetric key, which is then encrypted with the destination public key. This way, only destination private key can decrypt the symmetric key which was used to crypt the mail. So, we expect Thunderbird request a C_Decrypt using my private key and give some bytes (encrypted symmetric key), and with the returned unencrypted key, decrypt the mail. Easy, isn't it? After requesting for the pin, Thunderbird calls C_DecryptInit with mechanism CKM_RSA_PKCS and my private key handle. That seems OK. Then, it invokes C_Decrypt with some bytes (Always the same for the same mail...128 length), and we try the following: RSA_private_decrypt(ulEncryptedDataLen, pEncryptedData, pData, keyRSA, RSA_PKCS1_PADDING) where keyRSA its generated with:RSA_new() and d2i_RSAPrivateKey(...) (have checked and the private key its correct.Even more, we can sign with it without issues.) That code returns the same bytes always (128 length), but Thunderbird always says Thunderbird cant decrypt the message. Why this happens? Must we code C_UnWrapKey function and so to Decrypt, cause Thunderbird doesnt like our PKCS#11 just does CKM_RSA_PKCS? Are we missing a flag? Are we doing something wrong? Thank you all for any help you could provide. And btw...one more time (and hope last): I have 2 accounts for dev-tech-crypto discussions: dev-tech-crypto@lists.mozilla.org and mozilla-dev-tech-cry...@lists.mozilla.org which one is the correct one? what is each one for? should i stop using/delete one? are the same with 2 names for backward compatibility? Thanks a lot for your help. Much appreciated (Sended twice, first time without subject :S) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird encrypted mail using certificate (on smartcard) isnt able to C_Decrypt the message. Why?
On 01/20/2012 04:17 AM, helpcrypto helpcrypto wrote: After requesting for the pin, Thunderbird calls C_DecryptInit with mechanism CKM_RSA_PKCS and my private key handle. That seems OK. Then, it invokes C_Decrypt with some bytes (Always the same for the same mail...128 length), and we try the following: RSA_private_decrypt(ulEncryptedDataLen, pEncryptedData, pData, keyRSA, RSA_PKCS1_PADDING) where keyRSA its generated with:RSA_new() and d2i_RSAPrivateKey(...) (have checked and the private key its correct.Even more, we can sign with it without issues.) That code returns the same bytes always (128 length), but Thunderbird always says Thunderbird cant decrypt the message. This appears to be your problem. I have know idea what library you are using for your primitives (presumably openssl), but it clearly is not decrypting the key with RSA_PKCS1_PADDING. The expected result should be something like 24-16 bytes, which should be the symmetric key you encrypted with. The code makes me wonder what you are trying to do, however. It looks more like a 'simulated' smart card. I presume that d2i_RSAPrivateKey takes the actual private key that matches the public key used by S/MIME. Presumably the data is stored somewhere and you aren't just 'regenerating a new key'. If you were using a smart card, I would have expected a card specific APDU call which passes the encrypted data to the card and got the decrypted data back. Why this happens? It appears to be a bug in your code at this point. If you are using the correct key, and you are using RSA_PKCS1_PADDING, your RSA_private_decrypt should work. Must we code C_UnWrapKey function and so to Decrypt, cause Thunderbird doesnt like our PKCS#11 just does CKM_RSA_PKCS? Thunderbird is perfectly happy with CKM_RSA_PKCS. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
