Quote of the day—Claire Wolfe

We should be using email encryption even for sharing our chocolate chip cookie recipes.

Claire Wolfe
January 30, 2016
Weekend links
[I enthusiastically agree because of this:

Given that the NSA has taps on almost all of the internet’s major trunk routes, the PGP records can be incredibly useful. It’s a simple matter to build a script that can identify one PGP user and then track all their contacts to build a journal of their activities.

Even better is the Mujahedeen Secrets encryption system, which was released by the Global Islamic Media Front to allow Al Qaeda supporters to communicate in private. Weaver said that not only was it even harder to use than PGP, but it was a boon for metadata – since almost anyone using it identified themselves as a potential terrorist.

“It’s brilliant!” enthused Weaver. “Whoever it was at the NSA or GCHQ who invented it give them a big Christmas bonus.”

Given all the tools available to the intelligence agencies there’s really no need for an encryption backdoor, he explained. With the NSA’s toolkit of zero-day exploits, and old-day exploits, it’s much easier to root a target’s computer after identifying them from metadata traffic.

The problem is that encryption is a hassle. Until the hassle factor is significantly reduced it’s not going to happen.—Joe]


14 thoughts on “Quote of the day—Claire Wolfe

    • I’m with Publius on this. Ubu52 may be a bit annoying and sometimes I think she is deliberately trolling. But I don’t see any reason to be impolite to her or go out of the your way to say something mean.

      I’m not going to delete any comments or ban anyone unless thing got extremely out of hand. But that doesn’t mean I won’t frown at comments like that and mentally make a note of such comments as an indicator of character.

  1. Until the hassle factor is significantly reduced it is built into standard protocols it’s not going to happen.

    Fixed that for you.

    End to end encryption needs to be the standard for any communication. We are getting there with web service as more people move to various flavors of ssl, but email an other person to person communication is still lagging way behind, mostly because you need all the users to adopt the protocol (i.e. update their clients) at the same time in order for there to be a seamless transition. Rewriting the protocols to include end to end encryption would significantly help with that (as opposed to bolting on various flavors of often incompatible encryption onto the old standards, which do not handle it very elegantly). SMTPv2 and IRCv2 anyone? someone should probably work on that. . .

  2. I find PGP works surprisingly well with a mail plugin. My Mac has a plugin that makes it nearly transparent. Interestingly enough, one feature is that it automatically encrypts all drafts (no matter who they go to).

    This “encrypt everything” notion is why John Gilmore sponsored a Linux implementation of IPSec network encryption, way back about 20 years ago. The idea was to enable “opportunistic encryption” — encrypt automatically whenever both endpoints had the capability, whether it was “needed” or not.

    I’m half-tempted to use Tor as my primary browser on the same sort of reasoning.

    • IPsec works great as long as you trust all the nodes. Problem is for things like email you could get routed through an untrusted node that would be able to read the email before routing it on to the next node. IPsec is end to end on the tcp level only, but it is not end to end at the application level, which is what we really need. I’m not saying don’t use IPsec of course, it is the perfect choice if you trust the server you are connecting to, but for things like email that we basically cast to the wind it is not the right tool.

      Of course as part of a layered approach to security what I really want to see is TLS for link encryption, hiding IPsec for session encryption (we can stop here for transient communications like http etc.) protecting seamless application encryption like PGP (only better, and standard to the protocol). To get to the data you have to start at the bottom of the stack and work your way all the way up, cracking or compromising each layer in turn. Either that or you have to compromise an end point, which means you would have to specifically identify your target (instead of collect data in bulk).

      • You’re quite right. IPSec is certainly not a complete solution by itself, and wasn’t claimed to be. What it does is protect a whole lot of stuff easily and quickly, with a single set of machinery that doesn’t care what your application protocol is.

        By contrast, TLS (f.k.a. SSL) might protect a slightly longer pipe, but at the expense of being a lot more trouble (it has to be done separately for each application, and because TCP/IP doesn’t have a presentation layer, it has to be done as an application protocol variant with its own port number).

        Finally, if you have store & forward relays as is the case with email, then the only complete answer is encryption of that email, i.e., PGP. (Not s/MIME partly because hardly anyone uses it, and partly because it relies on central authorities for the certificates.)

        On the “prevent bulk collection” notion: yes, and just encrypting the pipe, as in IPSec, gets you almost all of that. As soon as the pipe is protected, email is, at best, accessible only at the ISPs that host the destination mail servers. That’s admittedly a significant concern which is why PGP matters, but it’s a whole lot more granular and raises the burdens on the spooks a whole lot compared to plaintext pipes.

        • Re: the email

          It is actually a lot easier to transparently hijack email than you think. All you need is a bogus MX record on your link and you can “transparently” rerout mail without really being noticed (you will be able to see it in the route list, but that is only assuming they dont go through the trouble to scrub it). And if you are the government getting access to those links is trivial. The only real way to secure email is to encrypt it on an application level.

          • Good point, and that subject (MX hijacking and the even sneakier BGP route hijacking) was discussed in a Wall St Journal article a few months ago. DNSSEC is potentially a help here, but not close enough to universal yet.

          • Yeah, and that touches on a much bigger issue. Our entire back end infrastructure is built on trust, from routing to name resolution to message delivery. If you value security this is not really a system that can survive in the modern world.

  3. I suspect the NSA will not pull their horns in until some bright boy comes up with the first generation of intrusion countermeasures (ICE) as depicted in various forms of cyberpunk fiction.

    Gets a lot harder on the budget when you try and root a target’s computer, and it promptly scrambles yours instead.

Comments are closed.