GNOME Bugzilla – Bug 331361
Allow GPG decryption with anonymous recipient set
Last modified: 2011-12-19 10:14:54 UTC
Please describe the problem: I use a private mailing list [0] that has an interesting feature set. To use the list you must have the lists gpg (public) key. You send an encrypted email to the list, the list server verifies your signature and decrypts the messsage. As far as evolution is concerned, this works perfectly fine. The server then consults to see who should get the message and encrypts it to everyone on the list. This is useful because only the server admin needs to keep the user keys updated, I do not need to know their key. I trust the server admin in this threat model. It's not perfect but it works. When the message is sent to everyone on the list, the list has the option of throwing the key-id[1]. If the message has the key-id thrown, the message is effectively anonymous. No key-id seems Here is how you can simulate the mailing servers type of anonymous message: gpg -e -a --throw-keyid -r jacob@appelbaum.net To see what it looks like when such a message is piped to gpg: gpg -e -a --throw-keyid -r jacob@appelbaum.net |gpg dsak gpg: anonymous recipient; trying secret key XXXXXXX ... Enter passphrase: You can also generate this type of message like so: gpg -a -e -R jacob@appelbaum.net Any message you encrypt will be blind to gpg or anyone else trying to find the recipient. When gpg gets the message, it does not have a key-id and thus has to try each of your secret keys until it finds the correct one. This becomes a problem when you have multiple gpg keys and multiple email addresses. It appears that evolution has several issues when dealing with these types of messages. [0] http://codecoop.org/projects/firma/ [1] http://lists.gnupg.org/pipermail/gnupg-devel/1998-August/014415.html Steps to reproduce: 1. Create an encrypted gpg message with a stripped key-id: gpg -e -a --throw-keyid -r jacob@appelbaum.net 2. Make the proper mime headers so that evolution will attempt to decrypt the message when the user opens the email. (alternatively, setup a firma list [0]) 3. The user must have more than one gpg key. (I have four, one per email address that's different) 4. The user will be prompted for their passphrase, evolution selects the first key in the key ring. It cycles through all of the different secret keys, even the correct one. It doesn't appear that evolution ever understands when you've typed the correct passphrase for the correct key. It never knows which key is the correct one as far as I can tell. [0] http://codecoop.org/projects/firma/ Actual results: Evolution reports: "Could not parse S/MIME message Failed to unlock secret key: 3 bad passphrases given." Expected results: I expect evolution to detect if the message is anonymous or not. It should behave differently when it detects a stripped key-id. In the case of a stripped key-id, I would like evolution to request the passphrase of each key and have it try all of the keys, not just three of them as it seems to do now. I assume this is because of the threshhold of incorrect keys is three tries. This doesn't work if you have four keys. It might not work if you only have one key. In my experience, the correct key can be the third one as far as I can tell, it still will not decrypt. I assume evolution has some sort of wrapper around gpg that fails when it sees this type of message. Does this happen every time? Yes. Other information: <ioerror> I think I've found a bug in the way that evolution handles gpg encrypted messages that are anonymously encrypted (Evolution 2.4.1 in ubuntu) <guenther> hehe <guenther> What is "anonymously encrypted"? <ioerror> gpg has an option to blindly encrypt a message <ioerror> This seems to confuse evolution if you have a weird setup <ioerror> I have four secret keys for four different email addresses <guenther> ioerror: I still don't get it... What does this do? <guenther> which option? <ioerror> let me dig it up, brb <ioerror> http://lists.gnupg.org/pipermail/gnupg-devel/1998-August/014415.html <ioerror> I think that was the first time such a feature was introduced <guenther> oh <ioerror> example: <ioerror> gpg -e -a --throw-keyid -r jacob@appelbaum.net <guenther> Right, and now Evo does not know which key to use, eh? <ioerror> when I get an email to that address, evo says: "give me your key for secret key number 1" <ioerror> and it tries three keys in a row, it never makes it to the fourth one <ioerror> which in my case is the correct key <ioerror> As such, I can never read these messages in evolution. <guenther> ioerror: Please file a bug in bugzilla, giving as much details as possible. <ioerror> Unless I missed, it could be fixed by setting a higher threshold of passwords to allo <guenther> oh, you can -- change the key order in your private keyring ;-) <ioerror> Sure, i can file a bug, where's the link to the bugzilla? <guenther> bugzilla.gnome.org <ioerror> Well, that's useless in this case, I have four email addresses all using similar thrown-key lists <guenther> of course <ioerror> no matter the order, i will always trip this bug unless I'm just totally missing something <ioerror> I imagine there's two other people in the world that even care about this feature though <guenther> yeah... <guenther> I guess the solution is not to raise the threshold. <ioerror> I am however talking to them with this list and so, I care ;-). I'm going to go file a bug now. Thanks for your time guenther, you've been helpful <guenther> But to make Evo realize, it needs to test all keys... Or ask which one to use. <ioerror> yeah <ioerror> I have key ids set for each address <guenther> letting the user choose (if possible here, dunno) would be good <ioerror> I suspect that evolution could say: "I see you have a default key for the address this was sent to, lets try that first, then do the next key in the order" <guenther> failing that, at least detecting that it is "anonymous", so it can alter the full list at least <ioerror> Then ask for passphrase for the next key until there are no more keys to try. <ioerror> yeah <guenther> mention *all* this :) <guenther> Please provide as much details, as possible. <ioerror> I'm just going to paste this chat likely and then explain the software i'm using <guenther> eh... <guenther> Whatever... I'd explain it, though. <guenther> ioerror: Out of curiosity -- Why are you using this? <guenther> I mean... The goal is to not "brand" the encrypted data stream with the key id. <ioerror> I am using an encrypted mailing list. <ioerror> The list has an option for blind encryption, so you don't know who the message is encrypted to <guenther> But since the message is delivered via the internet, the envelope shows the addressee in cleartext. <ioerror> ie: I don't know who else is on the list <ioerror> the software scrubs all the info, it's a remailer <-- ratschnowski has quit (... je me casse, a+) <guenther> uhm... <guenther> aha <ioerror> I only know that once I've decrypted the message, I have plaintext from the sender, signed and verified <guenther> This is weird, dude. :) <ioerror> anyone else watching is going to get a message from a server list that is blindly encrypted <ioerror> Make sense? <guenther> it does <guenther> it still is weird <ioerror> Good times. <guenther> :)
Created attachment 150230 [details] [review] proposed eds patch for evolution-data-server; Not as that big change. Are you able to give it a try, please? I tried few things and it seems to work fine, I'm asked for a password of "each" of my private key and then gpg tries one after each other. (actually it isn't each, as gpg picks only some of them.) Nonetheless, one can give it a wrong password and it'll survive. It also prints a hint about anonymous recipient in the password prompt, thus user is notified what's going on.
Milan: Does this (your) patch still make sense?
Ah, right, I forgot of this completely; mostly waiting for a testing, but yes, let's commit this. Created commit fa863a5 in eds master (3.3.3+)