When sending e-mail to several recipients, of which some are Bcc with the intention to hide them from the other recipients, using GPG leaks information about those because the used encryption keys are visible on the encrypted message. GPG has a -R option that hides the used encryption key, and this method is most likely also exposed through whatever KMail uses to run GPG. It should be used for all Bcc recipients in order to not disclose their existence! Reproducible: Always
Tracked in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748835
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
I jsut tested with 5.2.3, and it still has the bug.
Thanks for your feedback, Dominik.
At least for me, I can't reproduce it with 17.08.3, but it is fixed for longer. I used BCC from time to time and I can see in send folder, that Kmail created different mails. One encrypted for all shown recipients and additinal ones for each BCC recipient. I also analyzed the two encrypted mails with gpg cmd line, that the BCC key is not leaked in the mail. $ gpg /tmp/msg-normal.asc gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: encrypted with 4096-bit ELG key, ID 0xXXXX, created 2010-06-29 "recipient 1" gpg: encrypted with 2048-bit ELG key, ID 0xXXXX, created 2015-07-04 "recipient 2" gpg: encrypted with 4096-bit RSA key, ID 0xXXXX, created 2017-07-13 "sender" $ gpg /tmp/msg-bcc.asc gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: encrypted with 4096-bit RSA key, ID 0xXXXX, created 2017-07-13 "sender" gpg: encrypted with 4096-bit ELG key, ID 0xXXXX, created 2016-07-01 "BCC recipient"
Forget to mention, that I use Debian unstable, too.
Umm… > At least for me, I can't reproduce it with 17.08.3, but it is fixed for longer. > gpg: encrypted with 4096-bit ELG key, ID 0xXXXX, created 2016-07-01 > "BCC recipient" I really don't know what to say, but you just reproduced the bug and pasted a proof of it, claiming you didn't…
Well no: See the way Kmail solves this problem of not leaking hidden information is different than eg Thunderbird does. Instead of sending one mail to everyone, as is normally done in Thunderbrd, KMail sends different mails to different recipients. One mail is encrypted for the "normal recipients (To + CC)" and sent only to them. And then, for each BCC recipient, one individual mail is created and sent, all of which are only encrypted for one single BCC recipient. So the BCC recipients DO NOT see the other keys and more importantly, the normal recipients DO NOT see the keys of the BCC recipients, as this information is sent in multiple (depending on the number of recipients and if they are To, CC or BCC) individual mails. I don't see any leakage of keys here. The hidden feature of gpg would be needed if KMail were to send only one mail to all recipients. But the way KMail solves this issue (as described above), this hidden feature is not needed. And additionally also with the -R feature the "normal recipients" would see: 'okay the mail was encrypted for additional keys' (but without knowing what these keys are). Since KMail sends two types of mail, independent of each other, no information leakage is possible. And not even the information that there are BCC recipients (ie, that there are two types of mail sent), is leaked.
Sandro, could you clarify which information is needed to resolve this ticket?
In my opinion there is no information leakage, that's why I would close this bug as Resolved/Invalid. But I really want to be sure (as this topic is important to me), that there is no information leakage, that's why I want to keep this bug report open to give the reporter time to give more details, how he thinks this information is leaked. The information I need is a mail encrypted for keys where I have access to their private keys, that shows me the information leakage or a description how the reporter found out that there is information leakage, as I can't reproduce this.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!