Memory Hole discussion / OpenPGP e-mail header protection
Werner Koch
wk at gnupg.org
Tue Jun 30 13:07:53 CEST 2015
On Wed, 24 Jun 2015 15:26, wk at gnupg.org said:
> whatever you guys use these days) on the client there will be a need for
> unattended decryption. This raises the same security concerns as those
> with Enigmail's auto decryption.
What about using a second subkey to encrypt the header and the
"abstract" (top part) of the message? The bulk of the message would
then be a different sub-part and encrypted using the standard key. The
advantage is that you can auto-decrypt the headers and the "abstract"
while keeping the bulk encryption key on a secure medium (ie. a slow
smartcard).
Right, that would require a more complicated message structure but it
can also help to solve the mobile IMAP case: If the bulk is not a
sub-part but a separate second part, you would be able to download the
first part with the headers and the abstract of the message and display
that. Thus there is no need to download a large encrypted message.
|--- multipart/mixed
|--- multipart/encrypted
| |--- application/pgp-encrypted
| |--- application/octet-stream [1] [subkey-1]
| (decrypts to)
| |
| |--- multipart/mixed [2]
| |--- text/rfc822-headers inline [correct header]
| |--- text/plain [abstract]
|--- multipart/encrypted
|--- application/pgp-encrypted
|--- application/octet-stream [subkey-2]
(decrypts to)
|
|---- text/plain [bulk message] [3]
text/plain is only an example for any other MIME type. [3] should have
a dedicated header with the hash of [1] (or for robustness of [2]) to
bind the two parts. It depends on the MUAs on whether they can handle
this.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel
mailing list