Maniphest T2030

file names should not be embedded in the ciphertext
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	pinky
	Jul 3 2015, 5:28 PM

Description

Every gnupg encrypted file contains an embedded "original" file name.
GnuPG by default does not use this embedded filename. Other tools do. To prevent
security issues with such tools, the embedding of file names should be off by
default. Currently, embedding of filenames cannot be turned off (at least I
think so, based on the contents of the manpage).

Embedding filenames leads to security issues, as documented in the manpage of
GnuPG, option "--use-embedded-filename", or
http://www.cs.ru.nl/E.Verheul/papers/Govcert/Pretty%21Good%22Piggybagging%20v1.0.pdf
. As a workaround, I currently use --set-filename "" in my gnupg.conf.

And here is my story with embedded filenames:

I orginally sent a encrypted mail (using Thunderbird and Enigmail). THis mail
had an attachment, and when asked how to wrap it I selected "PGP/MIME", to save
the recepient the hazzle of decrypting and reattaching the attachment in case he
needs to forward it..

I got a reply that there was no attachment in my mail. So, the recepient
probably has a mailer that cannot do PGP/MIME. So I opened the original message
and clicked "Edit as new", then "Send", and selected "inline PGP" as format. I
got a repsonse claiming that something was wrong with the attachment, "please
find it attached for analysis". So I tried to decrypt it and got:

$ gpg --decrypt nsmail-1.asc
gpg: no valid OpenPGP data found.
gpg: decrypt_message failed: eof

Then I used my favorite editor to open nsmail-1.asc and found that it was the
plaintext version of the attachment.

What happened? I re-wrapped the mail form PGP/MIME to inline PGP. In this
process, the attachement name remained the same (e.g. "secret_document.txt"),
but the attachment was temporarily stored in the file system using the temporary
name "nsmail-1.asc". GnuPG embedded this temporary name within the ciphertext of
the attachment. Then, the MIME wrapping of the attachment contains the original
file name twice (once as "name" and once as "filename"). Recepients buggy tool
seems to use the embedded file name as final file name, while it probably should
use the MIME encoded name of the attachment.

Event Timeline

pinky added projects: gnupg, Bug Report.Jul 3 2015, 5:28 PM

pinky added a subscriber: pinky.

Sorry, gpg can't fix bugs in other programs. Having the filename in the cipher
text can be an important information and thus we won't change this. If you do
not want to have a filename embedded, simply do not use a file but pipe the data
to gpg (i.e. read from stdin or another file descriptor).

• werner removed a project: Bug Report.Jul 21 2015, 3:35 PM

• werner added a project: Feature Request.

What about adding an option to not embed the filename even if a file name was
given? It can be hard to convince other tools (e.g. enigmail) to use pipes for
just some of the operations ("cat %f | gnupg" for encryption, but not for
decryption). My workaround with --set-filename "" did not lead to problems yet,
so maybe this is good enough, from a usability point of view. Also, I just had a
look into RFC4880, and it seems that zero-length filenames are perfectly OK:
"This may be a zero-length string."

So your solution is fine and produces the same result as a new option. Okay to
close?

Solution is fine for me from a usability point of view.

For other users, it is not fine because they will first have to find this
solution, which probably will not happen before having fallen into the pit. So I
would prefer a changed default behavior.

I will try to convince the authors of the OpenPGP standard to remove some of the
complexity of the standard as well as the resulting issues.

pinky closed this task as Resolved.Jul 22 2015, 6:07 PM

pinky claimed this task.

file names should not be embedded in the ciphertextClosed, ResolvedPublicActions

Description

Event Timeline

file names should not be embedded in the ciphertext
Closed, ResolvedPublic
Actions