? 2010/11/10 Robert Relyea <rrel...@redhat.com>
> 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 >
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
