I don't think so. PGP scrambles the text of the message for you (that's the body), but you're still using the standard email protocol, which sends attachments without making changes to them. You'd need to encrypt the files before sending them. (And the recipient would have to unencrypt them manually.)

I think it very easily could. Email bodies are often MIME Multipart messages [0], which can be nested to arbitrary depth. You can see an example of such a message here [1]. The PGP setup used by default with Mutt will encrypt your cleartext multipart message (which contains your text, html, and attachments) and then send only the new cyphered body.

[0] http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

[1] http://msdn.microsoft.com/en-us/library/ms526560(v=exchg.10)...

I'm not saying that End-To-End does this, just that it is perfectly possible (and common) to encrypt the whole message.

H

It depends on whether they use PGP/MIME or inline PGP. Without installing the tool, I'm guessing they use PGP/MIME, because you pretty much can't use html email with inline PGP, and I doubt they're going to default to plain/text mails.

Their FAQ explicitly says that they do not currently support RFC 3156, "MIME Security with OpenPGP" (http://tools.ietf.org/html/rfc3156). I don't know this stuff well, but that makes me suspect that PGP/MIME is not currently supported.

For this to be able to send PGP/MIME emails, the webmail service would have to allow the client to uploaded a body which is not tampered with at all, and also to specify the mime type of the email. That way, you could upload a pre-built MIME structure to be used as the body, generated by the OpenPGP extension, which includes the encryted attachments.

This could work, but the web service would have to support it as well as the extension.

Then there is also the issue of how does the receiver read the message? The extension would need to be able to parse MIME, and allow access to the separate parts.

There is one textarea, and the contents of that get installed.

Why would attachments be considered part of the body?

Encrypt them before uploading them, and send the decrypting key in the body.

Because as far as the email protocol is concerned attachments are part of the body, just wrapped in a multipart MIME message along with text body.

But Gmail itself may handle attachments differently.

> But Gmail itself may handle attachments differently.

AFAIK, Gmail handles attachments the same.

When it sends them, yes, but this is more what I was referring to: https://news.ycombinator.com/item?id=7842868

Any decent PGP plugin encrypts the attachments.

Regardless of how e-mail protocol transfers attachments, GMail pre-uploads files to their servers when composing an e-mail, so if you want to encrypt them, you'll need to do it beforehand.

> Why would attachments be considered part of the body?

Because if you look at the low-level structure of email, "attachments" are just parts of a body that is in multipart/mixed MIME type.

If you look that low, the body isn't actually encrypted, just the parts of it that contain your data.

Answering the GP, that varies from one implementation to another. Most clients encrypt attachments, but it looks like this one extension only encrypts the textarea contents.

Right, I was responding to the "why would attachments be considered part of the body?", not describing whether or not the Google implementation actually did treat them that way.