On 11/10/2010 05:34 AM, Matej Kurpel wrote: > Hello, > I am implementing a PKCS#11 module for Thunderbird and I have stuck > upon a weird behavior of Thunderbird. Let me explain: > For the purposes of testing, I have created a second gmail account. I > have also generated the keys and certificate for this account but only > imported its certificate into Thunderbird (under the "People" tab in > Certificate Manager) - I did that in order to be able to send > encrypted messages from my primary account to this secondary account. > I have my certificate and private key (for the primary account) in my > token and all is properly configured in Thunderbird. > Now, when I send an encrypted e-mail from my primary account to my > secondary account and then try to read it (when it arrives), > Thunderbird is able to decrypt it for me. I don't understand why, > shouldn't that fail? It doesn't fail because S/MIME encrypts the message to multiple recipients. Each recipient's public key is used to wrap the symmetric session key that the mail is encrypted with. S/MIME doesn't encode the email address of the recipient, only a pointer to the key used (either a subject key id or the subject/issuer of the certificate used to encrypt the key). When decoding an S/MIME message, the client looks for any key that it can use to decrypt the message. In your test case, it's the key from your primary account, since the sender is also an implicit recipient (the message is written into the 'Sent' folder, and the sender needs to be able to read it).
If you delete your sender's private key (after backing it up, of course), you will find you won't be able to read the message. > I didn't give it the private key for the secondary account anywhere. > From the pkcs11-spy log I can see it's calling C_DecryptInit and > C_Decrypt as follows: > > > 66: C_DecryptInit > [in] hSession = 0x2 > pMechanism->type=CKM_RSA_PKCS > [in] hKey = 0x2 > Returned: 0 CKR_OK > > > 67: C_Decrypt > [in] hSession = 0x2 > [in] pEncryptedData[ulEncryptedDataLen] [size : 0x80 (128)] > 4559BE33 DE12B7F1 72909126 F9F16537 8638661F 588BBCDE 2B8E2180 > BC0E83BA > AC1A26C0 67A25DF0 7560B64F E3E726A5 09640A4E 47540E4A D5FE2A76 > 2116E61E > 783EC37A 5600ED67 E42988E5 D419AC4E 70395E7F 1D0FCA66 70049230 > D61E698F > F6DDB51B EC79FD78 68B880F6 80A3748E F874EBA9 A672C251 003B0339 > E7D8384E > [out] pData[*pulDataLen] [size : 0x18 (24)] > 673DB607 4ABCB3E0 431A9E0D 1991BC1C DCBC0208 70076D8C > Returned: 0 CKR_OK It's using the sender's private key. If the code is calling C_DecryptInit it means it has found a private key that it thinks should work on the blob that it is trying to decrypt. > What I have learned from this mailing list in the past is that > Thunderbird is trying to implement key unwrapping by calling > C_DecryptInit and C_Decrypt (and apparently this is what's actually > happening). However, for the unwrapping, it should use the private key > for the secondary account which it doesn't have, right? Instead, it > uses the private key for the primary account (hKey = 0x2) and, > surprisingly, succeedes...? Yup. that's because the primary account was the sender. > Please shed some light on this for me, if you know why it behaves like > this. > > M. Kurpel
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
