Encrypting / Signing the mail subject?

Patrick Brunschwig patrick at enigmail.net
Fri Jan 16 17:41:27 CET 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16.01.15 13:43, Hanno Böck wrote:
> Hi,
> 
> I wanted to share some thoghts about a potential change to the PGP mail
> format I had. I'm not sure if this is the right place to discuss this,
> but afaik there is currently no active openpgp standards list at IETF
> and gnupg is likely the only implementation in widespread use. I recall
> that I have read something alike already somewhere sometime, however I
> don't exactly remember in what context.
> 
> One of the things I find unfortunate about OpenPGP encryption is that
> the subject of a mail is not encrypted and signed. This is imho very
> bad from a usability point of view and also not really neccessary,
> because there are ways this could work without changing too much about
> the way pgp mails work.
> 
> What I have in mind is something like this: Whenever a PGP mail app
> creates a mail it replaces the subject with a defined keyword. This
> could be something trivial like "__ENCRYPTED_SUBJECT__". It then places
> a Subject line inside the encrypted mail body. This is followed by two
> newlines and then the real encrypted body of the mail follows.
> 
> A mail client supporting this format would then replace the
> __ENCRYPTED_SUBJECT__ in the UI with the Subject from the body and it
> would hide the Subject: ... and the two newlines from the UI display of
> the mail body.
> 
> Doing this would provide some kind of backwards compatibility to old
> clients. A client not supporting this mechanism would still be able to
> read a mail. It would also show the subject as part of the encrypted
> mail body. There would even be some compatibility in the other way. A
> user aware of how this works could manually set the subject keyword and
> the Subject in the mail body in a mail client not supporting this
> mechanism.
> 
> 
> There are some things that'd need consideration if such a mechanism
> would be created:
> * This would move the subject to the encrypted part of a message. A
> mail client may decide that it needs some kind of caching of mail
> subjects available, because it is not feasible to decrypt them on
> demand, especially on large mailboxes. Therefore a client might move
> data from the encrypted context to a nonencrypted storage. This is a
> trade-off, but imho it is still a lot better than not encrypting the
> subject at all.
> * One would have to make a clear decision how the Subject is encoded to
> avoid confusion and incompatibilities. Currently a subject with special
> chars has some kind of utf8-prefix-encoding. A mail body has its own
> encoding. One would have to decide if the subject encoding is just the
> body encoding or if the same format as in the header is used. Technical
> detail, but should be done right and should be unambigious.
> 
> So far my rough proposal.
> What do people think about it? Is this the right place to discuss it?
> If you like it do you think it should become a standard/RFC? Anyone
> interested in impementing it in whatever mail client implementation?

I get this feature request every now and then for Enigmail. I think that
encrypting the subject could prevent inexperienced users from leaking
information because they assume that the subject is encrypted.

However, my response is always the same: I would be willing to implement
this in Enigmail if and only if other mail clients would also implement
it and/or if this would be somehow standardized.

- -Patrick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUuT8yAAoJEMk25cDiHiw+N40H/2unTgG3DCm2DGWh1iSUXSsB
mpAQk5uhnab0kbWbsrFaMlwx49ibOh8GD1O9IuMIsNF1DDQCGqTVUcaK4ZXOTe73
cuvdaNUSP2eY7IlabAzObDZM4vCA3GU/IdRRJvmsd+cN2c/B81tduRitHgedt0mG
uctIo+44tZGRPGkDnIpFR7Dxh0OIr0BnBQvlb2WvBdOjRt5OXTZilbBw3ibnSUai
+MntQ51Z4yO/yf8mSCv2OFBZiQU9DQtQFuDZT12gCAT70rqC20F19LvpZ2qwH5GU
lcQ3SkyMKcSE+i5uVXruIfFh8UD7As6kmXKDOGgTpwPr8X3136UjsQB6U6087aU=
=7MzY
-----END PGP SIGNATURE-----



More information about the Gnupg-devel mailing list