Version: 1.8.1 (using KDE KDE 3.4.1) Installed from: Compiled From Sources OS: Linux encrypted/signed messages generated by Kmail are not secure. See http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html for a description of the problems. I'd like to be able to generate (and display) a secure message consisting of an encrypted/signed/encrypted message to avoid the security defects. But currently, there's no way to direct Kmail to do so. The process for generating such a message using PGP/MIME (RFC 3156) would proceed as follows: encrypt content with recipient's public key label as application/octet-stream and combine with application/pgp-encrypted, wrapped as multipart/encrypted package multipart/encrypted with recipient's public key (labelled as application/pgp-keys) as multipart/related sign multipart/related and combine with signature (application/pgp-signature) as multipart signed encrypt multipart/signed with recipient's public key and label encrypted data as application/octet-stream package with application/pgp-encrypted as multipart/encrypted Note that "content" may include message text, attachments, etc. The resulting message is encrypted (viewable by recipient only); within that encryption wrapper the encrypted content is signed along with the encryption key (verifying that inner content was encrypted by the signer and protecting against Anderson's attack). Coupling the inner encrypted content with the encryption key protects against a signature replacement attack.
We're implementing standards, so ietf-openpgp and ietf-smime mailing lists seem more appropriate for this stuff to be dicussed and codified than the KMail bugtracker.
On Thu June 9 2005 01:48, Marc Mutz wrote: [bugs.kde.org quoted mail] PGP/MIME (RFC 3156), a product of the openpgp WG, and S/MIME are based on a layering approach using the security multipart media types defined in RFC 1847. The example given in the wishlist item uses those types and is fully compatible with RFC 3156. The problem is that Kmail provides no way for a message author to specify specific construction of a secure message; the only mechanisms that are provided have known security holes and fail to provide what is implied (e.g. a message with attachments, and specifying that the entire message should be signed fails to sign the attachments). Note that the example provided was just that -- an example. Some authors may wish to treat some messages differently, e.g. by first signing, then encrypting the signed content, then signing again the encrypted data.
Bruce, I've skimmed through the paper now. This is not a technical problem, but a social one. One part of the problem (Alice loves Charlie) can be addressed by making sure you properly address the recipient inside the signed part ("Hi Bob, I love you. Alice."), the other part (forwarding of sensitive information received encrypted and then claiming the sender hadn't encrypted in the first place) could be addressed by S/E/S, but that leaks AFAIK. That leaves E/S/E, which can be had by attaching already encrypted attachments. I agree that it _might_ be nice to more narrowly control how the various multiparts are nested by KMail, but cryptography is already hard enough to grasp for the Average User (as much as I hate bringing that into a discussion, but for cyptography, that's the sad reality ATM). Bringing in these options has always the danger of luring the user into some false sense of security. So has the current way of doing things, but unless S/E/S or E/S/E becomes common practise, it's hard to argue about the added user complexity. I'm reopening it under a new summary, let's see whether someone find it attractive enough to implement.
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.