Why do encryption tools suck?

Wouldn’t a Microsoft product “secure” button simply cc the message to Homeland Security?

I guess with crypto, homecooked is best, ultimately.


That’s simply because they are far, far from being “totally secure”.

1 Like

The study pretty clearly shows that the difficulty is not anything inherent to PGP, it’s just that Mailvelope’s instructions suck are inadequate and the UI apparently isn’t great. But sometimes…

In another two pairs, Participant B was completely mystified by the encrypted PGP email and was unaware that they needed to install Mailvelope to read the message.

…there’s just nothing you can possibly do.

“We want you two to try to send each other an encrypted message, using this browser extension called Mailvelope. You can use any online resource you need.”
  …60 minutes later…
“I can’t read this gobbledygook!”
“Did you have trouble installing the Mailvelope extension?”
“The what now?”


Do tell? How exactly would you go about reading the content of my tutanota or protonmail email? Why is it that Cern, which developed protonmail, calls it “NSA proof” if it is “far, far from being totally secure” as you claim? I suppose that you have a hack the NSA doesn’t know about?

I don’t know about Protonmail’s security, but apparently its reliability (and judgement) is questionable:

They got extorted into making a ransom payment, which they did, and then got DDOSed anyway. Once you have paid him the Danegeld, you’ll never be rid of the Dane.


I’m technically sophisticated enough to learn to use them… I still don’t use them. It’s really just a pain-in-the-ass factor. If you already work in IT, this is likely something you’ve learned to do more routinely in the course of your work. If you’re like me, it takes a chunk of valuable time out of your day, and in the end you’re never quite sure you did it right.


Yeah I saw that. Nobody says that they were able to access the contents of emails, which would not be possible if they are telling the truth about their system. If you are on the internet you are vulnerable to DDOS and when I initially saw that the script kiddies only asked for $6,000 my initial reaction was that I would have paid it too. Some bad publicity nonetheless.

Personally I use tutanota because it’s open source so I don’t have to wonder if they are telling the truth like you do with protonmail.

1 Like

I apologize for being cryptic; it’s mostly just that the topic is big and hairy; and really painfully dull unless you happen to be atypically interested(as noted, MS’ interest, and Outlook’s capabilities, are really there because some companies want to be able to have their IT departments configure them and impose them on everyone else in the organization; not because any specific user is intended to set them up. It’s not unlike their support for smartcard authentication: in an ideal world, you can banish your lousy login password and get handy single-sign-on with a cryptographically secure hardware token that fits in your wallet! It’s just that, unless you do enough DoD work to be issued a Common Access Card; don’t expect to see that actually happen; but Microsoft had to support it, or lose a very important customer, so support exists).

In the case of Outlook, unless some third-party plugin is at work, ‘secure’ would mean that S/MIME is being used; most commonly with public and private keys attached to your active directory accounts(so that Outlook can fetch the recipient’s public key automatically just by looking him up in the internal address book; and the recipient will more or less seamlessly be able to decrypt the message, with their key available to them if they have logged in successfully; this mostly-transparent operation breaks down outside the organization in most cases; but it makes in-house stuff very user friendly).

Just as with SSL certificates for web sites and other servers; the users’ keys would be validated against a hierarchy(though usually with an internal certificate authority at the top; either a self-signed root that all the company computers are configured to trust, or an intermediate key purchased from one of the big CAs so that people’s phones and home computers don’t freak out when they try to access things from offsite.) If you want to know more; MS has a writeup for Server 2003 domains; more recent versions have moved the buttons around; but the concepts are largely unchanged.

If you don’t want the details; the big difference is that S/MIME and hierarchical PKI are not ‘web of trust’ arrangements like GPG/PGP; but are largely, for email, what SSL and certificate authorities are for web pages. On the plus side, this makes using them pretty easy. On the minus side, as the endless parade of ‘Certificate Authority does something unbelievably stupid and/or Evil’ reports have shown; having a ‘trusted root’ is something you do because building a ‘web of trust’ is tedious; not because it’s safe(especially if the CA is actively hostile to your privacy, rather than merely incompetent).

The TLDR is basically that, if you accept a ‘trusted authority’, it is comparatively simple to get encrypted email traffic between the other clients that also trust this authority; just as using a browser to access a website with an SSL certificate issued by a CA you both trust is pretty painless. By contrast, PGP/GnuPG ‘web of trust’ arrangements(even if the UI issues are sorted out) don’t offer much automatic-just-works; but do not rely on any central trusted authority(even the ‘web of trust’ is optional; you can choose to exclusively trust keys that you have exchanged with somebody else yourself, courier-with-handcuffed-briefcase-style, though this obviously limits your circle of contacts).

For the web; nobody likes it; but everyone has mostly sucked it up, pretended that a bunch of CAs are actually trustworthy and run SSL accordingly; because we needed buying stuff on the internet to work.

For email; this hasn’t happened: S/MIME is conceptually fairly similar; but you would only expect to see it in an organization where the ‘trusted root’ is internal; and only people directly related to the organization; or specific outsiders brought in for some reason, do anything except plaintext email.

GPG doesn’t need a hierarchy; so it can be used if even just one other person cares enough to exchange keys with you; but, in practice, behold the howling wasteland of indifference.

(An aside: in college, I set up GPG for my mail client; and signed all messages by default, which allowed the recipient to verify their integrity if they were GPG-aware; but didn’t break reading them for those who weren’t. In that time; I had one contact who saw the signature and sent an appropriately encrypted reply so that we could stop sending plaintext emails. Coolest philosophy professor I’ve had.)


As far as I’m concerned, if you’re doing your email in a browser and relying on a browser extension to handle the dirty work, you’re doing at least two things wrong.

Unfortunately, the best secure email set up I’ve seen discussed is also very inconvenient because it is encrypted messages over POP3 using the Mutt email client on an encrypted local disk. You want your email? Well, there is just this one computer here with all of it.

And it wasn’t until Greenwald and Poitras worked with Micah Lee of EFF that they were able to communicate more-or-less securely. I’d venture a guess to say that most people still don’t entirely understand what end-to-end encryption is or why it would be useful to them on anything other than the most abstract level.


I use encryption on occasion as part of my day job doing security at Mozilla. PGP usability with Enigmail and Thunderbird is still so horrid that I still (years later) occasionally screw up on encrypting and decrypting emails.


Email as a protocol is the postcard of communication formats, really. It wasn’t designed with security in mind, there is no envelope involved in it. The best you can do is send an attachment with a different key to unlock than your key you use to access your mailbox.

Part of the charm of systems like Slack is that they don’t use email at all, and are restricted to just the team members.


From RFC 822 (13 Aug 1982), defining the standard of ARPA Internet Text Messages [now known as email]:

 1.1 SCOPE

      This standard specifies a syntax for text messages that  are
 sent  among  computer  users, within the framework of "electronic
 mail".  The standard supersedes  the  one  specified  in  ARPANET
 Request  for Comments #733, "Standard for the Format of ARPA Net-
 work Text Messages".

      In this context, messages are viewed as having  an  envelope
 and  contents.   The  envelope  contains  whatever information is
 needed to accomplish transmission  and  delivery.   The  contents
 compose  the object to be delivered to the recipient.

(Thankfully, in more recent revisions, “compose” has been corrected to “comprise.”)

1 Like

That’d require a whole new set of interoperability standards and perhaps its own protocol… That’s expensive, and unlikely to end up being adopted quickly enough for such an idea to take hold, no matter how bone-headedly obvious and good it is.

Don’t worry about it. I’m setting up End-to-end encryption (well… I’m just doing a small part of the work, configuring security devices manually, since we don’t seem to have a scriptable API for that kind of thing at the moment) for chip and pin rollout at our retail stores.

We offer the best encryption the DoD has to offer… in 1998. Apparently, our particular system has to be able to fall back to triple DES.

But rest assured, your banking information is totally safe with us!

ETA: Oh, here’s some publicly known evidence that the payment card industry considers triple DES good enough for all your money that isn’t cash

1 Like

PGP plugins/encryption tools arent the problem and pretty much haven’t been for decades. The problem as others have pointed out is key/certificate management, the good ol fashioned “web of trust” problem that has dogged PGP since it first came out.

1 Like

Oh, they refer to it as an envelope, but it doesn’t protect the contents from view. It is a cellophane envelope. There is nothing there to keep the mailman from reading it.

1 Like

And you can’t run your own server so they are centralized under one corporate entity, making subpoenas and illegal monitoring via NSLs much easier.

Don’t get me wrong, after being required to be on IRC every day for my job for almost a decade, I love slack and run a “team” on it but I’d love it a lot better if the code was all open source and I could run my own server.

1 Like

I didn’t say it was perfect, and until they release the promised Slack in a Box, at my current company we can’t use it, despite how good it is. Contractual security obligations.

Anything you post to Slack should be considered public. I use Slack daily, but NOT because it is secure, because it is group IM for teams.

Slack security is a joke, but the entire idea behind slack is transparency with minimal containering between users/groups/companies. The mobile and web apps offer “keep me logged in” which only require a cookie. Both the browser version and the mobile versions post notification to the OS when new messages arrive. There is no notification when you log in from a new device, no way to force sign outs from other devices, the bot api has admin level access to all of a companies posts, etc. etc.

There security is minimal at best: Security at Slack | Slack
They have been hacked: Slack's Security Breach May Be Worse Than It's Letting on
They let employers read your private messages: Slack now lets employers tap workers' private chats | Computerworld


1 Like