It’s not very often where I get to say “wow, if he had only used Emacs, most of those usability problems would have been avoided” but here we are.
And then your correspondent replies without crypto, quoting your original plaintext.
I never thought of that, but perhaps simply sending an encrypted attachment as nickpsecurity suggested below could help here? Unless they cut and paste from that into their reply, keeping relevant context as a considerate email user should ;-)
It was a consideration of mine. The original solution was Compartmented Mode Workstations running OS’s such as Trusted Solaris or Argus Pitbull. They broke system up into security domains with a label representing each one. That was per file, window, I/O port, whatever. There was also a security policy for how labels could interact.
Although sold to stop hackers, one of best benefits of CMW’s is preventing accidental leaks through methods such as cut and paste. That combined with proxies and guards pretty much had the email/messaging security air-tight.
Not saying your system was/is, but compartmentalised systems might be subject to other issues. I once emailed my bank and weeks later got forwarded their response from a third party with a similar email address to mine. (Only difference was .org vs .no.) I don’t know, but I suspect that compartmentalised systems meant they couldn’t simply hit reply but had to type in my email address and got it wrong. (Possibly due to autocomplete.)
That’s an application layer issue that could hit you on a CMW. Really needs human review. There was a defense in earliest of mail guards where they whitelisted the sites and addresses. The guard would drop anything to an unlisted destination with an error log. Secrets could still go to someone else on the list from there but this helps in intranet scenarios. It’s at least internal people that are less likely (on average) to use it for doing damage.
Let me contrast the author’s experience with my own. Note that I had a brain injury during this process that made me forget scripting and GPG plus hard to learn. I’m a nice test case for how hard things are. :)
So, I looked into GPG. Holy shit there’s a ton of options and complexity. High-assurance security says subset to minimal thing that works for increased trustworthiness. I noticed it could encrypt files with others' public keys. The person that contacted me was able to receive attached files. Text editors only have so many 0-days left in them & are easy to sandbox. So, I decided on this protocol:
Type the message into a text file.
Type a cryptic command to encrypt it with that public key.
Attach the file to a message to that person. Optionally doing this on a different box passed through a data diode if I was worried about GPG box compromised. Just using Linux for now.
Receiving works other way where I download an encrypted file that I run a decryption command on.
So, that’s simple. How to get started and what commands to use? I installed GPG first. One look at the man page made me hit Google instead. I found a cheat sheet, identified the minimal commands necessary, and compared them against the man page. Saw what seemed to be right stuff but that man page was horrible. Looked at a bunch of other sources online with varying trustworthiness to see if they had same commands. Seemed like I had the right ones. I was also warned the key gen phase could take a long time so I just ignored that usability problem that stomped the OP so much. I was warned after all.
The key generated. Messages sent and received well. Only thing left was tediously typing my new buddy’s email into the box with every encryption. As others came up, I was having to remember more email addresses. Time to automate that shit with a front end that worked on any system I needed. Also, without remembering how to program.
I recalled Python was easy. So, I’d need a data structure for a list of (alias, email) pairs, basic operations on text for maybe substitution, input, conditionals, ability to print them, and spawn function of some kind. Python reference gave me all I need which I tested each to be sure then composed them with tests. End result was a Python script with the list of alias/emails in it like a config file where I could just add people to the script itself. Then, I run the script on the text message with it asking which of a listed group of people to send it to. I type in number or name for it to run command automatically. Then, I verify by eye the new file looks like gibberish and attach it to the email.
End result was that I had GPG for friends using it, I figured out how to use it with fair degree of trustworthiness, and I automated the annoying part with less than beginner’s knowledge of scripting. This shows GPG is way less hard than it appears to be. Although I sure could use a great front-end to smooth over all this. I’m sure any half-ass programmer could create one given what I did in that state. :)
How many hours did you pour in to learning and perfecting your workflow?
1-2 I think. That’s because I did the verification of Google results and relearning some scripting. The GPG cheat sheet was one of top results for Google on first search.
Encrypted email will always be a pain, because we’re bolting on encryption to something that wasn’t designed from the ground up to support it, and where there isn’t a strong market demand for a good solution to the problem.
Because, here’s the thing: encryption isn’t a feature. It’s not something you add. It has to be central to your model, even if you aren’t going to use encryption 90% of the time, you need encryption built into the entire application stack of the tool in question. Email simply doesn’t have that, and its format is so ancient at this point, that adding it is a challenge.
TLS was added to HTTP about 5 years after it was first created. HTTPS has been fairly successful, though not nearly as much as it needs to be. Including it on the model would have been better, but email doesn’t really have an excuse to not be encrypted by default.
There’s a key difference here, though- TLS is not actually part of HTTP. It wasn’t “added” to HTTP, not specifically. I mean, it’s right there in the name, isn’t it- transport layer security. HTTP (and SMTP) are application layer protocols, and there’s nothing that stops you from using TLS with SMTP (and, in fact, this is routinely done). By that standard, we already have an encrypted email solution that works- but not in any application layer.
Edit: And yes, I know that in the OSI model, TLS is actually a Presentation layer, not Application, but for this exercise, that’s a distinction without difference.
You’re right about the demand side but not tech side. The earliest, high-assurance systems solved this problem with proxies and guards. The guards, eg mail guards, were original solution that did site to site protection inspecting the traffic and doing crypto themselves. Designed to be as bulletproof as possible. Client-side complications such as broken formatting or need for end-to-end crypto led to proxies (eg Nexor Sentinel) that sat between client and guards on client’s endpoint. They do any processing necessary to ensure the use of crypto is pretty seemless for the users of legacy clients.
Trick still works today with companies still selling such solutions. FOSS or others just need to copy that approach. Well, we already see something similar with plugins like Enigmail. Proxies (or proxies + plugins) are stronger since they can be done sandboxes, memory-safe, etc. Guards could be dond with OpenBSD, Linux with SVA-OS, etc.
While I agree that the bar to entry is pretty high with PGP/GPG. I think a lot of issues could be mitigated with a bit of knowledge about cryptography in general. EFF’s SSD seems to be a pretty good starting point!
Also I feel like decoupled encryption systems like PGP are invaluable, even in systems where encryption was built in from the get go.
AFAIK ProtonMail is trying to make mail encryption accessible to end users.
So much of this would be solved by using keybase…
The bar to entry is still pretty high - even with keybase (sure users can have keybase generate the priv keys, but there is risk involved in that). Also keybase seems to want to move away from pgp because “no one wants to unlock their key every time”.
Also keybase seems to want to move away from pgp because “no one wants to unlock their key every time”.
Huh? GPG has supported agents for years.
Sure, GPG does.. but I am talking about keybase. Here is the “stance” they are taking now. - your options are to keep using gpg the way you have (not n00b friendly) or - let keybase keep a copy of your private key which increases attack surface.
Also their new chat app doesn’t use PGP (first entry in the FAQ).