

To PGP/MIME or not to PGP/MIME - HerraBRE
https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html

======
darklajid
I just started looking into PGP (well, gnupg to be honest).

The plan is to both use gpg for communication/email, but also for backups
(duplicity), secret stuff/passwords (pass) and authentication (ssh).

For that I'm (not affiliated) using a yubikey neo¹ for now. Advantages:

\- Very easy to set up (works for signing, encrypting, authentication already)

\- Contains the key material on the 'smart card'

In addition my main key is ~elsewhere~: After loading three subkeys on the
yubikey I saved and removed my main key from the keychain. This _should_ solve
the problem of the airgap in this article? A reasonable way to get access to
your data/mail without giving access to your secret key?

Things I am confused about/haven't thought through yet/reasons to not switch
to use it completely yet:

\- I'm confused about the key backup solutions here. Keys generated on the
smart card cannot be backed up as far as I can see. I have a decent idea of
how I'm going to handle my master key (both where and how I'll store it
safely), but .. the rest is still not quite clear to me

\- Mobile. So, if my day to day keys are on this smart card, I cannot read
those mails on my mobile. Which .. might be a good thing when we talk about
security, but a PITA for my day to day usage. No idea how or if I can solve
this one

But back to the article: If you're in the "whistle-blowers, activists, spies"
category, is the airgap (physically) really required or would a smart card
give you the same protection?

And the

>Mail clients implementing some sort of "Email Manifest protocol" could agree
to move critical headers out of the main message and into the encrypted
manifest as often as possible

line seems overly optimistic in my opinion. Repeat after me: Microsoft
Outlook. And .. the introduction is basically PGP/Mime doesn't work everywhere
and/or needs plugins first (-> Bad user experience). Is a brand new proposal
that wouldn't work anywhere for quite some time really the answer?

1: I got an older release, so no U2F for me, but this is - among other things
- a 'smart card'

~~~
mike-cardwell
> If you're in the "whistle-blowers, activists, spies" category, is the airgap
> (physically) really required or would a smart card give you the same
> protection?

Smartcard doesn't protect you if your Internet facing machine is compromised.
With a separate air gapped machine, you could print out the cipher text from
the Internet connected machine, then scan it in/OCR it into the non-Internet
connected machine and decrypt it there. Then you could encrypt a response on
the non-Internet connected machine, read the cipher text back in to the
Internet connected machine via scanning+OCR and send it out.

~~~
TheLoneWolfling
...Assuming your input stack on your non-internet connected machine is
uncompromisable.

In practice, this is decidedly not the case. OCR is complex. Your attack
surface is not exactly tiny.

~~~
a1369209993
_Good_ OCR is complex. "Here's a jpeg with 80 lines of 80 characters (from a
set of 64 ascii characters chosen for maximum descernability); do your best
and I'll run that through a ECC that cuts down to a 32KB chunk." is rather
less so. Also, there's no reason your OCR program needs any permissions other
than reading a single jpeg and writing a single text file.

~~~
TheLoneWolfling
You can make the same argument about a non-airgapped computer, though.

I don't see any advantage of this over (say) it connected via a dead-simple
serial connection.

------
diafygi
This does make sense and is backwards compatible, though what about HTML
messages? Will you add the simple to/from clutter to the top of the html
content, too?

Instead of trying to extend the standard, why not just nest an unencrypted
email in an encrypted email? I'm thinking along the lines of:

1\. Someone writes their message into the client and attaches some files.

2\. The client generates an unencrypted, standard multi-part email message as
message.eml.

3\. The client then pgp encrypts message.eml to message.eml.pgp.

4\. The client then generates a new email with message.eml.gpg as an
attachment and sends it.

5\. The recipient receives the message and sees one attachment
message.eml.gpg.

Most native clients can open arbitrary .eml files as email messages. This
makes it much more convenient to interact (reply/forward/etc.) with this
technique, and it is also HTML message compatible. Also, if you have a PGP
plugin for your native client, it would decrypt the attachment, and you could
just double click it to open that message to read/reply/forward/etc.

As far as web clients, most can't decrypt pgp messages so you'd have to
download the message.eml.pgp. And I guess you'd also have to have something
that can read .eml files. However, it should be fairly easy for pgp-enabled
web clients like Mailpile to open these messages since they have to already
have a message format parser.

Anyway, thanks for the article!

~~~
HerraBRE
Thanks for reading, and thanks for the feedback!

HTML mail is certainly a problem - editing HTML in that way is not nearly as
easily done (nor reversed) as plain text. This is a loose end in the current
proposal. Like many techies, I'm somewhat guilty of wishing HTML mail would
just go away... However, in all fairness, HTML mail is not often used with PGP
today and is somewhat of a "luxury" item, not a critical part of how people
communicate.

I did consider embedding a full message/rfc822 part instead, and that is also
what Werner (the GnuPG author) prefers as well. If PGP/MIME had been
implemented that way in the first place, and clients had evolved with that in
mind, I'd probably just be happily using that.

Unfortunately, the way message/rfc2822 attachments are handled by current mail
clients, is not nearly streamlined enough that I'd be happy making people jump
through those hoops for every single message.

I'm trying to find a sweet spot of working well enough with existing PGP-aware
clients, better with PGP-unaware clients, and addressing the limitations of
PGP/MIME at the same time. It's a bit of a balancing act and so far the
easy/elegant solutions don't seem to pass muster when used in the real world.
But I'd love to be proven wrong about that.

------
barnaby
Good article. I wonder why Mailpile are targeting difficult use-cases such as
activists, journalists, etc. It feels like every PGP provider aims for this,
but OTR encryption tools aim for a much easier use case: average users who
just want to hide their private conversations from big data algorithms which
then sell their secrets publicly. OTR is much easier as a result, but it can't
do email (that I know of). :-(

In this article mailpile worry about users who need an airgap. What worries me
is whether creating features for airgap users makes anti-features for users
like me who just use PGP when mailing with my parents, my wife, and some
friends. We just want to avoid our secrets being part of "Big Data" and as a
side benefit we resist passive surveillance. Mailvelope (which is "easy") is
complicated enough for my parents, they would never add the complexity of an
airgap. We just want easy encryption, even if it isn't totally NSA-proof.

~~~
HerraBRE
Fair question. :-)

I mentioned those users as one group that was impacted, not as the be-all-end-
all target audience. If you re-read the relevant section you'll see I spend
more words worrying about Mailvelope and Google E2E users. They face the same
issues.

------
brians
Looks like a fine start. Compressing chunks together seems pretty dangerous;
the ZIP file part is only safe if it doesn't compress.

~~~
HerraBRE
There have been some security flaws related to compressing data before
encrypting it - I don't know if those apply here. But if they do, well,
compression is actually optional in the ZIP standard. This would need to be
checked carefully if this moves beyond the discussion stage.

The purpose of using an archive was primarily to have a standard container for
transmitting filenames and metadata, which recipients won't need to install
extra tools to work with.

~~~
JoshTriplett
If you use ZIP, some implementations will compress, and you'll get security
vulnerabilities. And even if your implementation rejects compressed ZIP files,
other implementations won't. Better to use a container that doesn't support
compression and never will; for instance, tar.

PGP/GPG has compression support built-in, for that matter; I wonder if anyone
has looked for vulnerabilities like CRIME or BREACH in it?

~~~
HerraBRE
I suggested ZIP simply because it's so widely supported, it's built into the
stdlibs of many higher level languages and most operating systems have GUI
tools to browse the contents. I don't know of any other containers that are as
widely supported, but I am all ears.

If it's a container that requires the recipient install 3rd party tools, then
we may as well skip that part of the proposal entirely.

------
pflanze
Meta comment: the website is mostly unreadable with JS disabled because the
fixed-position head is covering most of the page, but fine when removing the
"position: fixed" from the "navigation" class. (And your target audience will
generally be one that prefers to have JS off, I'd think.)

~~~
HerraBRE
Thanks, I'll file this as an issue on our site's tracker.

~~~
donatzsky
Another issue I noticed: In the FAQ the line spacing is way too small.

Firefox, Windows 8.

[http://imgur.com/x8zIXFT](http://imgur.com/x8zIXFT)

~~~
HerraBRE
Thanks! That one already had an issue filed:
[https://github.com/mailpile/www.mailpile.is/issues/9](https://github.com/mailpile/www.mailpile.is/issues/9)

;-)

------
higherpurpose
If we could use a forward secure PGP, I think that could be worth breaking PGP
backwards compatibility. Isn't the TextSecure protocol kind of that anyway?
Why can't MailPile use that with an e-mail interface? It's forward secure,
it's asynchronous and you can authenticate users. What more do we need?

~~~
HerraBRE
Mailpile is an e-mail client, first, other things second. Maybe we'll support
other protocols, such as TextSecure, at some point. I hope so, actually! :-)

Note that PFS generally applies to a communication channel, not the way a
message is encrypted and signed for long-term storage. TextSecure decrypts
messages and stores them using a different algorithm locally - there's no
forward secrecy if someone steals your local TextSecure message store.

Sadly, the only such separation we have in the world of e-mail (at the moment)
is the TLS wrapper around SMTP/IMAP/POP3, which can and should use PFS
ciphers. But that doesn't help if the server itself is malicious. That's one
of the reasons I'm keen to try and cut out the middle man when possible, and
deliver "directly" from client to client. See our SMTorP discussion for one
idea of how we might eventually do that:
[https://github.com/mailpile/Mailpile/wiki/SMTorP](https://github.com/mailpile/Mailpile/wiki/SMTorP)

