On 03/14/2014 04:42 AM, Leon Brits wrote: > Robert, > > Thanks for your time. > >> cmscipher does call DecryptUpdate, but for the symmetric portion, not the >> asymmetric portion. We were talking about key unwrapping/decrypt in RSA. >> This is clearly an symmetric operation (DES3 or AES or something). > Ok. Sorry if I misunderstood and gave the incorrect answer. > >> Looks like you are trying use a PAD mechanism when NSS requested a CBC >> mechanism. In the CBC mechanism NSS will always ask for even number of >> blocks and expect to get back all the blocks. In the PAD mechanism, the >> PKCS #11 module needs to hold back one block in order to handle padding >> correctly. > I simply provide the PKCS11 interface, Thunderbird must decide which PKCS#11 > call to do. In thunderbird I encrypted a message and now I want to decrypt it > on another machine with Thunderbird. I only told Thunderbird which RSA > certificate is used as the targeted party. So if Thunderbird now wants to > decrypt it should know what it did and make the right PKCS#11 calls. What you supply is important. If you supply more of the PKCS #11 interface, then you need to implement what you supply correctly. That's fine to do. If you just implement the minimum, Thunderbird will use softoken (which has a correct implementation of C_DecryptUpdate for AES_CBC). NSS tries to keep the operation in the token with the key and only moves it when necessary. If you don't want this to happen, you need to 'break the chain' somewhere. If you're OK with proceding with the rest of the operation, then you just need to make sure you are doing PKCS #11 correctly. That means if I ask for C_Decrypt on CKM_AES_CBC, if I give you full blocks, you need to return all the blocks (you don't hold one back). > I got the DecryptUpdate() call which means Thunderbird must call the > DecryptFinal() at some point (IMO).
It looks like we do have an issue in the error path, but fixing that won't make your token work. If we are bailing it's because you incorrectly implemented DecryptUpdate(). We'll just close out the session. > >> Can't call decrypt here, because I probably have more blocks coming. >> This is encrypting the email message, so it's streaming. > It is decrypting. It's a streaming decryption. We get data sent from Thunderbird piecemeal. There are lots more blocks we need to decrypt, the few blocks you have are not all there is. If you implemented C_DecryptUpdate correctly for the mechanism we requested, you would get another C_DecryptUpdate call. > >> The fundamental issue here is you are probably trying to do more than you >> need to if you just want a signing/decryption token. You don't need to >> implement the symmetric algorithms, so if you just implement decrypt >> (rather than unwrap), NSS will use it's internal implementation to do the >> symmetric operations. NOTE: Please read this paragraph. This is where you are having the problems. Once you fix this, you will get a proper C_DecryptFinal(), life will be fine. >> >> If you are trying to build a full replacement (because you are managing >> the keys in your token or something, then you need to return all the >> blocks requested when doing a CBC operation (rather then a CBC_PAD >> operation). > We do have a VERY complete implementation of RSA, DSA, DH, EC, wrap/unwrap, > en/decrypt, sign/verify and derivation on our device. We expose this all via > PKCS#11 v2.2 and up. That's fine, but you need to implement C_DecryptUpdate correctly. If you just want things to 'work', you could simply just drop wrap/unwrap from your RSA support. NSS will decrypt and insert the decrypted key into softoken. > And for them all, if you call DecryptUpdate() then you must call > DecryptFinal(). As far as I know this is the standard. Please correct me if I > wrong. That is correct, please write a bug against the fact that we fail to finalize on our error path. Be aware, however, that once we fix this bug, you will still have problem decrypting because we are in the process here of shutting down the connection. You will get the C_DecryptFinal call, but we S/MIME will still fail to work with your token. t > > Regards, > LJB >
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
