To PGP/MIME or not to PGP/MIME(mailpile.is)
mailpile.is
To PGP/MIME or not to PGP/MIME
https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html
6 comments
Hi. I've recently done something similar with the OpenPGP Smartcard V2[1] (YubiKey seems nicer now, but I don't think they existed when I got mine. In any case, they both seem to perform the same GPG operations, mine can also only hold 3 subkeys, etc).
> 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?
The way I understand it the reason for keeping your main key seperate from the card is so that in case you lose the card you can still issue revocations and issue new keys signed by your master key. The smartcard still contains three seperate secret keys, but does indeed not expose them to the computer.
> 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
Personally I've opted against having my smartcard generate the keys, because like you said this means it is impossible to extract the subkey used for encryption. Instead I generated the keys on a Raspberry Pi, used paperkey[2] to print them to paper (don't forget to also print some instructions on how to restore, in case you forget or someone else has to do it), and also burned them to a few CDROMs. Then I transferred them to the smartcard, keeping them on the Raspberry Pi's SD card as well, which I keep in a secure location with the CDRoms.
> 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
I've been wondering if it would be possible to install opengpg on a rooted android phone and then seeing if it were possible to connect it to an usb smartcard reader using an OTG cable, but honestly I think that'd mostly just be a lot of wasted time and effort, and possibly insecure. I tend to carry a chromebook around and instead use that.
> 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?
I think a smart card could give you similar protection, if it were to work perfectly. I don't think we can be absolutely certain they aren't backdoored, which is easier to make sure with a basic linux install on a computer that has never seen the internet. Additionally, if you were to use a smart card on a computer attached to the network, the plaintext would exist on that computer at some point which would be a problem if a keylogger or similar were present.
[1] http://shop.kernelconcepts.de/product_info.php?products_id=4...
[2] http://www.jabberwocky.com/software/paperkey/
> 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?
The way I understand it the reason for keeping your main key seperate from the card is so that in case you lose the card you can still issue revocations and issue new keys signed by your master key. The smartcard still contains three seperate secret keys, but does indeed not expose them to the computer.
> 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
Personally I've opted against having my smartcard generate the keys, because like you said this means it is impossible to extract the subkey used for encryption. Instead I generated the keys on a Raspberry Pi, used paperkey[2] to print them to paper (don't forget to also print some instructions on how to restore, in case you forget or someone else has to do it), and also burned them to a few CDROMs. Then I transferred them to the smartcard, keeping them on the Raspberry Pi's SD card as well, which I keep in a secure location with the CDRoms.
> 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
I've been wondering if it would be possible to install opengpg on a rooted android phone and then seeing if it were possible to connect it to an usb smartcard reader using an OTG cable, but honestly I think that'd mostly just be a lot of wasted time and effort, and possibly insecure. I tend to carry a chromebook around and instead use that.
> 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?
I think a smart card could give you similar protection, if it were to work perfectly. I don't think we can be absolutely certain they aren't backdoored, which is easier to make sure with a basic linux install on a computer that has never seen the internet. Additionally, if you were to use a smart card on a computer attached to the network, the plaintext would exist on that computer at some point which would be a problem if a keylogger or similar were present.
[1] http://shop.kernelconcepts.de/product_info.php?products_id=4...
[2] http://www.jabberwocky.com/software/paperkey/
> 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.
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.
Thanks. My fault. You answered my question, but I asked the wrong one in the first place.
Given this sentence in the article:
>An "air gap" is a low-tech, widely understood method of protecting secret key material from being compromised. If we send PGP/MIME formatted mail, air-gapping becomes inconvenient to the point of being infeasible.
my question was: Wouldn't a smart card
- prevent the compromise of one's secret key
- therefor allow sending PGP/MIME stuff again quite easily?
(your airgap explanation made sense of course)
Given this sentence in the article:
>An "air gap" is a low-tech, widely understood method of protecting secret key material from being compromised. If we send PGP/MIME formatted mail, air-gapping becomes inconvenient to the point of being infeasible.
my question was: Wouldn't a smart card
- prevent the compromise of one's secret key
- therefor allow sending PGP/MIME stuff again quite easily?
(your airgap explanation made sense of course)
...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.
In practice, this is decidedly not the case. OCR is complex. Your attack surface is not exactly tiny.
For computer <-> computer communication, you don't need to print in plain text. Print things as barcodes (or qr or whatever you fancy), then scan them over there - those are much easier and more reliable to parse.
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.
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.
I don't see any advantage of this over (say) it connected via a dead-simple serial connection.
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!
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!
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.
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.
Looks like a fine start. Compressing chunks together seems pretty dangerous; the ZIP file part is only safe if it doesn't compress.
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.
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.
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?
PGP/GPG has compression support built-in, for that matter; I wonder if anyone has looked for vulnerabilities like CRIME or BREACH in it?
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.
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.
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.
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.
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.
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.
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?
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
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
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.)
Thanks, I'll file this as an issue on our site's tracker.
Another issue I noticed: In the FAQ the line spacing is way too small.
Firefox, Windows 8.
http://imgur.com/x8zIXFT
Firefox, Windows 8.
http://imgur.com/x8zIXFT
Thanks! That one already had an issue filed: https://github.com/mailpile/www.mailpile.is/issues/9
;-)
;-)
Odd, looks fine for me with NoScript in use...
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'