Testing the Usability of PGP Encryption Tools

“Why Johnny Still, Still Can’t Encrypt: Evaluating the Usability of a Modern PGP Client,” by Scott Ruoti, Jeff Andersen, Daniel Zappala, and Kent Seamons.

Abstract: This paper presents the results of a laboratory study involving Mailvelope, a modern PGP client that integrates tightly with existing webmail providers. In our study, we brought in pairs of participants and had them attempt to use Mailvelope to communicate with each other. Our results shown that more than a decade and a half after Why Johnny Can’t Encrypt, modern PGP tools are still unusable for the masses. We finish with a discussion of pain points encountered using Mailvelope, and discuss what might be done to address them in future PGP systems.

I have recently come to the conclusion that e-mail is fundamentally unsecurable. The things we want out of e-mail, and an e-mail system, are not readily compatible with encryption. I advise people who want communications security to not use e-mail, but instead use an encrypted message client like OTR or Signal.

Tags: , , , , ,

Posted on November 12, 2015 at 2:28 PM • 75 Comments

Comments

Required • November 12, 2015 2:43 PM

I have recently come to the conclusion that e-mail is fundamentally unsecurable.

That seems wrong. Fundamentally and from a user’s point of view, emails are arbitrary text data with an arbitrary text subject you can send and receive asynchronously.
Everything else is implementation details.

There is nothing making this fundamentally harder to secure than instant messages, it may be even easier thanks to the relaxed synchronicity requirement.

keiner • November 12, 2015 2:50 PM

Problem: Nobody has a key. Nobody has a functioning infrastructure, not even large companies. It’s really a shame years after Snowden. No end in sight…

Carlo Graziani • November 12, 2015 3:13 PM

Well, could the security aspects be pushed down to the transport protocol level?

What I mean is, if we take “e-mail is fundamentally unsecurable” seriously, it must really mean “SMTP is fundamentally unsecurable”, since SMTP is the common denominator here — if this weren’t the case, someone would have designed a usable cryptographically-sensible client by now.

So, what would the design of a secure message transmission protocol — comparable to e-mail, and possibly a drop-in replacement for it, to encourage adoption — look like?

Note: “securable”, in the context of this blog post, means “facilitating the adoption of cryptographic authentication and enciphering by people with just enough technical ability to use the current incarnation of e-mail”. Obviously, just adding support for cryptographic functions to packet headers is not that challenging. The question I’d like answered is, could this be done in such a way as to solve the sociological problem preventing true e-mail security?

Note2: Apparently, the one-time task of setting up an e-mail account is not an insuperable task for many people, despite the complications of IMAP / IMAPS / SMTP / SSL / TLS / port choice / etcetera. So why is the one-time (or few-time, anyway) task of setting up cryptograpy so hard?

Jack O'Connor • November 12, 2015 3:15 PM

@Required I think a lot of it boils down to this: If you can’t communicate with Gmail/Yahoo/whatever users, then what you have isn’t really email. If you can communicate with them, then you have to solve the so-far-unsolved problems around helping first time recipients get started, preventing replies in plaintext, teaching people to reject unsigned emails, and so many other things.

Davi Ottenheimer • November 12, 2015 3:20 PM

“The things we want out of e-mail, and an e-mail system, are not readily compatible with encryption”

I don’t know what “readily” means so it’s hard to disagree but I will anyway.

We want privacy out of e-mail and encryption has promise. My experience is that it sits in the tiny market space between two much larger ones: Not everyone will want to pay to make a safe system into one that is fast and easy to use. Likewise not everyone will want to pay to make safe the system that is fast and easy to use.

The problem is the lack of overlap to fund market growth in the middle.

If readily means easily, without cost or difficulty, then it seems you’re acknowledging that unfinished things are not finished. That’s a tautology. But if you’re saying quit because impossible to get funding into the gap between two markets, then I have to disagree. I still have hope we can get a balance of performance, usability and safety cost figured out for common users.

Kai Howells • November 12, 2015 3:27 PM

Apple have one of the easiest to use and straightforward implementations of S/MIME that it’s ever been my pleasure to use.

Put aside for one minute the difficulty of getting a “proper” verified certificate, as this step is complicated no matter which way you go about it.

The way it all works is this:

Once you have received your S/MIME certificate, you import it (by double-clicking) into your Keychain.

You then launch Apple’s Mail.app – and without any additional configuration, it shows two new buttons on what was previously a blank area of the window chrome above the area where you compose a new message – in the same area where there’s a drop-down menu to select the sending account and the signature you want to use.

These two buttons (a padlock and a tick mark) indicate the status of the email. Padlock button pressed in – message is encrypted. Tick mark button pressed in – message is signed.

All you then need to do is send an email to a recipient and if you have the signed option active, this will digitally sign the email and (by virtue of signing it) give them a copy of your public key. If you haven’t communicated with someone previously, you don’t have the option to encrypt, only to sign. Assuming they’re using Apple Mail.app as well, your public key will be automatically imported into their keychain. If they have certs set up as well and reply to you, they will have the option to sign and encrypt (they can just sign if they want, or sign and encrypt) and when you receive the email, your Mac will then automatically import their public key into your Keychain.

Once you both have each other’s public keys, you can then easily, and completely transparently, encrypt email communications between yourselves.

There is no additional configuration involved, you don’t need to tell Mail that you have a S/MIME cert, it finds it automatically and displays the UI to use it. You don’t need to send people keys manually, or manually import keys into a keychain, this happens automatically as well.

The only reason I stopped using it is because Outlook on Windows is so crap at dealing with signed emails that too many people complained that it was difficult to read my emails. The customer is always right. Grrr.

Of course this leaves aside the issues of the S/MIME certification infrastructure, which while it’s complicated nature is there for a reason, it is too high a barrier for entry for most people that no real progress has been made in trying to simplify it.

Now, it someone like Facebook or Google (that have a pretty good idea that we are who we say we are given the vast amount of personal information we freely hand over to them, and have the infrastructure for other people to verify our identity) were to step up as a S/MIME certificate provider, this could spur the adoption of secure communications – however the reality is that the vast majority of people simply don’t care…

Gregg • November 12, 2015 3:29 PM

I’ve got to agree with the first commenter ‘Required’ – when he points out the synchronicity problem with Instant Messengers. One of the reasons that email is more widely accepted than any instant messenger is that it is a store-and-forward protocol. Just like my DVR records television so that I can watch it on my own schedule, email will be waiting for me when I have time to read it. Instant messengers only work while you’re connected. Another benefit of email is that it is an open protocol while most instant messengers are proprietary and don’t play well with other instant messengers. At times, I’ve had multiple instant messengers installed just because everyone I needed to communicate with used a different IM.

Greg Slepak • November 12, 2015 3:31 PM

Schneier is mistaken. Only thing “fundamentally unsecurable” about email are the TLDs it uses. Add a blockchain to it and it suddenly becomes easy to secure it.

Wayne • November 12, 2015 3:36 PM

Sorry keiner, will have to disagree. I work for a big company and we have a fully functional PKI infrastructure. When I want to send secured email I simply make sure my smart card is inserted and check the little encrypt box on the email I am composing. Is that infrastructure cheap, heck no. Is it easy, heck no. Does it work, heck yes.

Gerard van Vooren • November 12, 2015 3:42 PM

Bruce, may I ask what you recommend for LAN with multiple architectures? Btw, what do you think of the use of SHA1 and the RSA 1536 bits group size in OTR?

Martin Walsh • November 12, 2015 3:58 PM

Perfect Forward Secrecy does not mean quantum resistant. Several years from now those emails you send today, they’re fair game if TLS is broken. Just think about the threat model and decide for yourself.

Anura • November 12, 2015 4:01 PM

End-to-End encryption of email is a very difficult problem, due to the requirements of email. It should be offline, allow anyone to send just by knowing your email address, and it should be searchable, with years of archives.

So for the first point, this requires a new public key infrastructure. Start with your email address – you need to generate a public key and have it signed by the host, meaning your host needs to have a certificate that is trusted by the sender. Of course, this brings all the same problems as the existing PKI for SSL websites. The real solution here is to leverage DNSSEC, but you also need a system that will verify the validity of the certificates signed by the host key.

Now you need a protocol where you give an email address to the mail host, and it responds with the email address – what if the person you are sending to hosts their own mail and their internet connection is down? Right now, it’s a problem if your SMTP server is down, but if both need to be online then you add an extra failure point – small problem, since it only matters if you don’t already know their public key, but it is a problem nonetheless.

So, now you have the email, but what happens if your computer dies and you don’t have a backup of the key? All emails stored on the server are unrecoverable. What if you want to access your email from a public library because you can’t afford a smartphone or computer? Yes, there are real security risks to doing so, but this is a real issue for people today, even in a rich country like the United States. You also have a usability issue, in that if you want to get email on both your phone and computer, you have to put the private key on both devices.

Okay, so you have you have solved all of those issues, so what if you want to search your emails? If you have years worth of email, especially if you use it for work where you have a dozen emails a day, the only way they are reasonably searchable is if they are stored on your local device – this can easily be tens of gigabytes of data, and every device you want to search on has to have its own copy of the data. How much can you store on your phone? This is why IMAP searching is invaluable.

The point is, you can work around all of these problems, but they result in large fundamental changes to email itself, to the point where the end product is significantly more limited and less usable.

Grauhut • November 12, 2015 4:42 PM

@Bruce: “I have recently come to the conclusion that e-mail is fundamentally unsecurable. The things we want out of e-mail, and an e-mail system, are not readily compatible with encryption.”

I dont think so.

Imagine a “mail shortcurt” function inside the mail client and as a proxy in front of an existing mail server, analog ricochet’s ths and something dkim for ths name propagation. An alternative direct mail transport via tor. There wouldnt even be visible metadata in transit, mail could be sent from client to client and be mixed there with plain old mail for indexing.

Grauhut • November 12, 2015 4:59 PM

@Gregg: “One of the reasons that email is more widely accepted than any instant messenger is that it is a store-and-forward protocol.”

So we have to integrate a transport secured a store-and-forward protocol and server into the Mail client.

@Anura: “What if you want to access your email from a public library because you can’t afford a smartphone or computer?”

Sometimes you cannot save everyone.

Jeff Niles • November 12, 2015 5:08 PM

The fact that Mailvelope is using inline PGP means it’s yet another broken PGP mail client to be tossed in the pile with all the others. Most clients get this wrong. If even software developers can’t get PGP basics right, regular users have no hope.

zomg • November 12, 2015 5:18 PM

“..but instead use an encrypted message client like OTR or Signal.”

client like OTR? I thought it’s an encryption method?

Daniel • November 12, 2015 5:22 PM

I wish Bruce would explain his reasoning more.

My own view, FWIW, is that I have an intuitive dislike for anything that requires two people to be live at the same time. It’s like a drug deal–the riskiest part of a drug deal is the exchange because two people have to be in the same place at the same time. I conjure up these images of the FBI breaking down a hacker’s door while another agent is chatting with the hacker on-line to keep him occupied. Con men have a saying that one should never be in the same room as a mark and his money. I’ve always thought there was a lot of (evil) wisdom in that philosophy.

So while IM does not require two people to share the same physical space it does require two people to share the same window of time. And that strikes me as a significant operational weakness. I’ve always thought the the real advantage of e-mail is that it breaks the communication connection both in time and in space.

Donovan • November 12, 2015 5:27 PM

The study didn’t even touch on the major reason I consider email to be fundamentally unsecurable for the masses: “I didn’t do anything wrong, why should I care?”

Nick P • November 12, 2015 5:30 PM

@ Bruce

Companies like Nexor have been doing secure email/messaging for a long time by combining solid plugins for legacy clients, proxies for the protocol, and optionally guards for extra security. Such methods tend to work best within rather than between organizations. That’s a compatibility rather than security issue: politics getting in the way. Not sure the usability of them as they’re too pricey for me haha.

However, solutions such as Hushmail, ZixCorp, SafeGmail, and, per Kai, Apple’s Mail.app were quite easy for people to learn to use. I believe such usable interfaces could be combined with proven implementation strategy of organizations like Nexor to get secure, usable email. I see no technical reason this couldn’t happen. Although, I imagine various organizations’ setups might require some hackery at the backend and proxy levels. Great thing is that this is invisible to users. They see same easy native or web interface as before with an extra command (sending) or notification area (receiving).

Note: I remember Colin Robbins said it has to work with the legacy clients seemlessly (hence proxies/plugins) to get adopted in most organizations. Another person also pointed out search must be supported somehow as email unintentionally became the most widely used knowledge management and long-term storage solution for business. Can’t overlook these two issues if one is aiming for the part of the market resisting adoption of dedicated clients.

tz • November 12, 2015 5:34 PM

If you used the TLS/SSL SMTP protocol between computers within your own network, and an encrypted disk for the host, it might work transparently with PGP as maybe an afterthought layer.

The problem is we keep emails on public servers.

Consider if we both have proton mail accounts, or maybe unseen.is They would be secure.

tyr • November 12, 2015 5:37 PM

If my memory is working correctly (possibly not) wasn’t
email implemented by some high school kid and college
student living near Berzerkley. From there it began to
suffer from endless creeping featurism until we wound
up with the current mess of brain damaged crap that
masquerades as email. The idea you might want to send
text messages to each other has been smothered under
trying to advertise, surveil and subvert you commercially.
Make it horrible to secure from the predatory corps.

How about re-inventing the wheel ? Start with the premise
of sending encrypted text messages P2P with all of the
protection built in from the beginning. Then you can
think about adding popping windows, file transfers,
fancy fonts and colours later.

Try this feature. If your system gets an encrypted email
it automagically answers back asks for the public key
and adds it to your keychain. This is after it checks
to see if the key is already there on your keychain.

One advantage to KISS is that you can understand what is
going on if you try.

Nick P • November 12, 2015 6:03 PM

@ tyr

That’s what all the encrypted messaging solutions do that aren’t email haha. The trick with secure email is that it has to preserve the properties, benefits, and workflow of email. Or modify it very little. Otherwise, it won’t get adopted. A major problem with secure messaging replacements is that many don’t understand how email is actually used by people and with what constraints. Then, they build replacements that can’t get adopted.

Note: A good example is how your messaging tool/config cuts text off at just under 4 inches. Had I not known that, the secure replacement I built whose word wrap assumes a whole page might not have appealed to you. 😛

Dirk Praet • November 12, 2015 6:27 PM

@ Kai Howells

Apple have one of the easiest to use and straightforward implementations of S/MIME that it’s ever been my pleasure to use.

S/MIME is for casual convenience and will only protect (the content of) your mails from snooping spouses, children, co-workers, managers and sysadmins. Assume most CA’S are either incompetent, only in it for the money and/or pwned a long time ago. The entire infrastructure is totally broken and which has been discussed many times on this blog.

Of course this leaves aside the issues of the S/MIME certification … it is too high a barrier for entry for most people that no real progress has been made in trying to simplify it.

There’s still a couple of CA’s out there (e.g. Comodo) that issue free certificates for personal usage. The process of requesting and collecting one is about as straightforward as preparing a tv dinner in a microwave oven.

If someone like Facebook or Google were to step up as a S/MIME certificate provider …

Facebook has recently introduced PGP messaging.

@ Anura

The point is, you can work around all of these problems, but they result in large fundamental changes to email itself, to the point where the end product is significantly more limited and less usable.

I think you just nailed it. Just on the PGP side it’s already too complicated for mere mortals, both technically and OPSEC-wise. The closest thing to secure email for ordinary people today is getting a Protonmail account, registered from a throw-away email account on a machine that can’t be tracked back to them, and then only ever access their mail over Tor. Preferably using TAILS or Whonix on a 5 to 10 years old machine used for nothing else and camouflaged as an ordinary XP box with an old pr0n collection and Gmail account.

@ Larry

Signal? Are you sure?

Until someone publishes a devastating audit report on both Axolotl and ZRTP, yes. Signal is also available on Android now, so no more pesky Signal/RedPhone interoperability issues. And do stay away from Telegram. I believe the Egyptian government recently announced they caught dozens of Da’esh (IS) militants by tracking their Telegram usage.

LessThanObvious • November 12, 2015 7:03 PM

It’s email with strangers that really is without an idiot friendly solution. Encrypted email within an organization is doable in a way transparent to the user. One reasonable solution would be to expand the concept of an organization so that a trusted communications infrastructure can be available. If the organization can’t be trusted it fails, if the NSA demands the data, it fails, but if Johnny wants to send Suzy an encrypted email anywhere in the world it can be ensured that Billy can’t read it so long as Johnny and Suzy are sending mail only in their organization so that the message never needs to be read by an untrusted server.

Paul Dodd • November 12, 2015 8:28 PM

@ Daniel

“So while IM does not require two people to share the same physical space it does require two people to share the same window of time. And that strikes me as a significant operational weakness.”

Not really. There are offline messages.

Dalton • November 12, 2015 8:30 PM

Regarding email being unsecurable, I don’t agree and I think companies could be the ones to push it for communications with partners. Securing intercompany mail seems fundamentally much easier than interpersonal mail. One reason is that companies view themselves as the endpoints—”end-to-end” means company A’s mail server to company B’s (unlike the 1980s, we’re not routing through intermediate SMTP servers anymore). Publishing their mail server’s TLS key in DNSSEC might be enough. Apple, for example, can and should insist they be able to exchange mail securely with the companies that build their hardware.

A good protocol would optionally allow for user-key lookup too, so you can look up the key for alice@example.com and use true end-to-end encryption. It could happen automatically on the sender’s server (again, companies can mandate this of their partners, and can set up their client machines to generate and use keys). And there’s no good reason we can’t register something like d4aggrya4coogpvp.onion as a mailserver (with some new resource type if not MX). The sending server would have to identify itself using a real domain to prevent spam, maybe by sending a chain of DNSSEC results. But it would be an easy way to impede traffic analysis.

None of the preceding stuff is particularly difficult, technically. Postfix already supports DANE via DNSSEC (RFC 7672), and this can be enabled per destination if necessary. The rest would be easy enough to program if people agreed on a standard.

tyr • November 12, 2015 11:12 PM

@Nick P.

So you’re saying if email gets fixed it won’t be
email any more. : ^ )

The only innovation I ever brought to programming
was to bulletproof user inputs by wrapping them
to the beginning with a screen blink if they were
outside of the program parameters. You could bang
on the keys all you wanted but it only let you
know something had happened with the blink. When
you hit a valid choice it went off did the task
and returned to where it should go. Nothing of any
great import but almost never seen in the programs
of others for some reason. The programmer shouldn’t
depend on others doing the right thing for them or
assuming that they will conform to some imaginary
set of standards. That way lies madness as we say
in the Mythos community… : ^ )

I see Snowden is recommending Qubes now that might
get it some momentum.

keiner • November 13, 2015 12:55 AM

@Wayne

Congrats! But with whom outside your shiny company do you communicate via encrypted email? Zero, I guess…

koana • November 13, 2015 1:46 AM

There’s a problem most discussions do not look over: publicly writable key servers.
So an attacker can put his key with your address and there is nothing you can do against.
As long as there are no trustworthy key server put methods there will be no security enhancement.
A very uncomfortable solution is the direct exchange of keys…

Martin • November 13, 2015 2:02 AM

Isn’t Signal integrated with Google? Nothing against Google in general, but e.g. I can’t install Signal on my Android phone, because it does not have access to any Google Services, but uses F-Droid.org. That’s too limiting for my taste.

Alex • November 13, 2015 3:59 AM

Perhaps the answer is to integrate the public key and the e-mail address, because you must have an e-mail address to participate in e-mail. If the signup process generates a keypair, and the public key is kept somewhere like DNS, it only costs a roundtrip per time-to-live to query for it and use it at send-time. Rather than DNS, you could also have a protocol extension to ask the example.com MX for user@example.com‘s public key.

Not Over Yet • November 13, 2015 6:05 AM

E-fail sucks balls and leaks far too much meta-data.

It is a horse and buggy evolutionary ancestor that should be taken out back and shot.

These two programs (Pond and Ricochet below) should be funded heartily by someone who cares about privacy as a serious alternative to e-fail.

BTW Where are the generous billionaire benefactors? Anybody going to stand up to the plate?

POND

Asynchronous messaging using hidden Tor nodes, Axolotl encyption, limited meta-data (time stamp, unique ID), no spam possible, messages deleted after a set period:

“Pond consists of users and servers. Servers exist in order to provide availability by accepting messages for a user while that user may be offline. Servers may be freely chosen by users and each user may have their own server if they wish.

Pond assumes the existence of an overlay network that prevents a network attacker from learning which servers a user is connecting to. That network is taken to be Tor for the remainder of this document and servers are Tor hidden services.”

RICOCHET also looks very good with zero meta-data, and no intermediate servers (Tor hidden services again):

“Ricochet is a peer-to-peer instant messaging system built on the Tor Network hidden services. Your login is your hidden service address, and contacts connect to you (not an intermediate server) through Tor. The rendezvous system makes it extremely hard for anyone to learn your identity from your address.”

If our over-paid government hackers want to take down every single email provider that isn’t part of PRISM (Proton Mail etc), while they’re busy doing that these peer-peer protocols should be heavily strengthened in the mean time, with a view to them eventually replacing email altogether in the future.

The asynchronous element is proven possible; just more techniques are needed to defeat the global adversaries doing complete network analysis.

A massive scaling up in the Tor network by a factor of x10 or x100 would also be great, especially since in other news, the FBI is paying universities to de-anonymise Tor users at $1 million a pop…

Bruce, please write something about the criminals in the universities being paid with blood money. You probably know the guy/team running the specific faculty in the case referred to on the Tor Project website today.

It is a disgrace and the American police state simply has zero ethics or morals, along with the cowards in both academia and the corporate world who will do anything for cash.

What? • November 13, 2015 8:10 AM

@Nick P

ZixCorp provides a far from ideal solution.

Zix can decrypt the contents of any emails sent via their service (it’s buried within their policies). They provide an online portal for non Zix users to access their messages.

An even bigger flaw in my opinion is that if two mails servers say they support TLS then the message will be sent ‘unencrypted’ (they assume that the information provided by the TLS server is genuine). This fundamentally undermines end-to-end ‘encryption’ as it again relies upon trustworthy (or even non-defective) mail servers.

JohnP • November 13, 2015 8:18 AM

Average people just need help setting up GPG in their fat-email clients. After that, with reasonable defaults, it just works.

I know this is true because my 80+ yr old mother and I exchange highly secure emails. Encryption to me is automatic for her.

Gotta protect those family recipes and other secrets, right?

Fix the setup. The rest already works fine.

mike~acker • November 13, 2015 8:21 AM

generally the technical analysis of this issue misses the essential key point: how do i get my public key authenticated and uploaded?

i should be able to take my public key to the DMV, Credit Union, County Record Office, or Notary Public and have it authenticated. These services are already required to be able to authenticate personal identifications .

once the key is authenticated how do i put it in service ? again, the DMV etc should countersign my key for me and upload it to the public key server

after than i can sign forcritical documents such as business e/mail — and important stuff such as tax returns — Forms 1040

which resolves to a simple technical issue : how do i generate my key and carry it to the DMV etc service ?

we need a PGP Key Device — like the key carrier we used in the US Army Signal Corps.

the key device would generate my keys and be portable so i could take it to the DMV etc. for service

connectivity: probably near field radio — with a stub for your PC like a USB Wi-Fi stub . this must not be incorporated into smart phones — those things are a mess.

there will be opposition from the usual suspects — but we need to overcome that .

Vesselin Bontchev • November 13, 2015 8:27 AM

Mailevelope is an unusable piece of shit that simply doesn’t work. (Although the fault might not be entirely Mailvelope’s; it is forced to depend on the web forms presented to it by the webmail providers and these constantly change.)

I know perfectly well how public key cryptography works – in fact, I was even on the PGP International development team for a while – and even I couldn’t make Mailvelope work (with Yahoo! Mail).

Now, take a real e-mail client, like Thunderbird, install Enigmail on it, and sending and receiving encrypted e-mail becomes a breeze.

Also, the article confuses PGP with GPG. (It talks about “PGP” but actually means “GPG”.) The two aren’t even remotely the same and are not even fully compatible with each other.

Name • November 13, 2015 8:35 AM

It’s very hard to correctly implement end-to-end encryption because computers are powerful and there’s a large trade-off due to that: you can’t know what they’re doing even if you designed the mainboard and OS yourself.

After I heard the Snowden NSA revelations I put together an old box with a new SSD and made it my internet machine. It has Win7, A-V, Malwarebytes, Firefox and the Tor Browser Bundle on it. Plus a Password Safe, VLC and IrfanView, but THAT’S ALL. I also disabled web Cookies/History, failed to install Flash, started using NoScript and stopped using Email. [Luckily I can get by without email; many cannot.] I xfer DL’d files with a single-purpose USB stick. My surfing experience has suffered but not much, while my relationship with my government has improved greatly – not that they know.

If my air-gapped machine has a problem, I re-install. I guess… I haven’t had any that I know of.

So this is all I can contribute to the conversation:
If you’re worrying about the NSA entering your house via wire/fiber/wifi (you are, right?), then get an air-gapped internet-only machine. It’s how you do security these days. Cheaper but Harder is Stupid And Wrong, Less Cheap but Easy is the only safe, therefore correct, route. Don’t sweat, spend instead.

One other thing:
It is only a matter of time before all govt. spying capabilities are implemented in Hardware, not Software. If you’re planning a hardware upgrade, ie. MainBoard, do it soon (don’t buy Lenovo). As for routers etc, I don’t know enough to comment, unfortunately, except don’t buy American, Chinsee or Russian if you don’t have to.

Here’s Reddit’s most recent AMA conversation with William Binney, former NSA senior official turned “pro-public renegade”; it’s recommended reading.

Matt Bury • November 13, 2015 8:43 AM

Hi Bruce,

Thanks for sharing!

My experience with corporate and govt. clients who wanted to send sensitive information concurs with the researchers’ findings. Even when I’ve set up a mail client with PGP and key pairs for them and took them through how to use it, the majority still had difficulty and ended up just using regular unencrypted email out of frustration. Only the most geeky of us find it logical and simple.

Matt 🙂

herman • November 13, 2015 10:49 AM

@Donovan
Anything can be planted on your unsecured email and computer. That is why you should care.

Someone doesn’t like you? Stick a Daesh manual on your PC and sit back and watch what happens next time you cross the border to go on holiday.

Nick P • November 13, 2015 11:30 AM

@ Dalton

There’s some potential with DNS/DANE but some issues, too. I’m holding off on building on it until pro’s figure out best risk mitigation strategies. Thomas Ptacek writes here about the specifics. The centralization was all I needed to know to dodge any reliance on it.

@ tyr

Nah I’m saying the fix must remain email. Several fixes did. Interoperability and cost were their main issues. Any fixes that aim to do that well or better must likewise preserve what email is and possibly some tools people use for it.

“The programmer shouldn’t
depend on others doing the right thing for them or
assuming that they will conform to some imaginary
set of standards. That way lies madness as we say
in the Mythos community… : ^ )”

It definitely helps to keep the users from shooting themselves in the foot. The more seemless, the better.

“I see Snowden is recommending Qubes now that might
get it some momentum.”

It will. Not sure if that’s a good thing. I wrote an essay of the past and present situation in secure, desktop virtaulization. Clearly shows Qubes isn’t up to resisting NSA and might reinforce that Snowden isn’t as qualified to recommend defence as he is understanding their offense. Alternatively, he might just be recommending it to slow them down. (shrugs) Most of these people haven’t even heard of a covert channel analysis… (sighs)

Although she’d never give me credit, Joanna must have been affected by my critiques as she added some suggestions and has reversed her position on Xen’s security after a number of years. Matches mine. 😉

@ What?

“ZixCorp provides a far from ideal solution.”

I totally agree and don’t recommend them. I tried to be specific that it’s usability is worth attempting to copy. Especially how it’s usable in several situations where other solutions are a bit difficult. I named off others so comparisons could be made to various approaches.

The trust and implementation issues are intolerable. However, the usability and marketing strength are supported by their financial report showing they’re making $50+ million a year in subscriptions since 2003. Not bad for a SME selling the kind of product people usually hate in a competitive market. I think usability and integration are what got them so much market share. Hence, worth trying to match those in any secure solution we develop.

@ Vesselin Bontchev

“Now, take a real e-mail client, like Thunderbird, install Enigmail on it, and sending and receiving encrypted e-mail becomes a breeze.”

That’s actually a really, good point. Reading the paper made me confused given the number of solutions I’ve seen that people picked up with ease following tutorials. Had never used Mailevelope, though. Thanks for confirming my intuition that the study may have set its users up to fail by mistake.

Clive Robinson • November 13, 2015 11:42 AM

@ Grauhut,

There wouldnt even be visible metadata in transit, mail could be sent from client to client and be mixed there with plain old mail for indexing.

This has been discussed on this blog before and what you suggest only addresses part of the problem.

The first issue to resolve is setting up an initial “trusted side channel” to agree and share a number of secrets that will be used in future. This is a necessary step to get around third party trust issues that exist in the likes of PKI etc.

The problem you are then trying to resolve are,

1, Secure “future encryption” of the message.
2, Annoymous transport to the store.
3, Anonymous storage.
4, Anonymous storage search
5, Anonymous retrieval from the store.

That is you have to assume that your enemy observes not just network choke points but all message stores as well. Which is not going to be an easy set of tasks to resolve.

For the sake of brevity I will call steps 2-5 and it’s infrastructure an “Anonymous Storage Network” (ASN). Further I’m going to make a fundemental –possibly incorrect– assumption that we will be able to solve any QC issues that might arise, or that QC will not become a reality in any kind of foreseeable future.

The first thing to note is that perfect forward secrecy involves a series of steps that do not require direct P2P communication. Provided you armour each communication step (hence the secrets) it can be done through an ASN.

Steps 2&5 requires a “mix network” that does not have the traffic analysis issues of ToR. Resolving these is possible, and there have been discusions here befor on sorting this out.

To be an ASN the mixnet requires a suitably large number of long term storage nodes to which anonymous posting can be made and found (steps 3&4). The properties of such nodes are an open discussion, for obvious reasons messages can only have a finite existance time, and there needs to be a way to prevent Storage DOS attacks. Further there needs to be a way of ensuring that file names are not just unique but anonymous as well (step 3a). The sender needs to communicate this file name and storage identity to the recipient (step 3b) so that the file containing the encrypted message body can be retrieved by the recipient.

Which means that there has to be some kind of anonymous distributed database (ADD). I’ve posted about this before, but my thoughts are still in flux about it. The problem “being able to search anonymously whilst being observed”.

A simple way to do this would be to have a fixed length record of three fields. The first is a short integer of say 16bits, and you pull down all records that have that have that field set to a number you mutually agreed when exchanging secrets. Thus an observer sees you pull down a thousand or so records only one of which is of relevance. This record is determined by the second field that is an agreed upon armourd string format encrypted by a secret key. Knowing the key the recipient can quickly check each records second field to see if on decryption it makes sense. If it does the third field can be decrypted to get the short message.

The short message could be not just the names of the file and store but other things such as the steps of a perfect forward secrecy key agreement.

Obviously the protocols for this short message service ADD need some care in designing.

Anyway, that gives you and others a 20,000ft view to think about, pick holes and discuss in other ways then maybe produce an RFC.

Daniel • November 13, 2015 11:49 AM

@Paul Dodd

“There are off-lime messages”

Then functionally how is it any different than e-mail? It seems like word games now.

Grauhut • November 13, 2015 12:56 PM

@Clive: “The problem you are then trying to resolve are,

1, Secure “future encryption” of the message.
2, Annoymous transport to the store.
3, Anonymous storage.
4, Anonymous storage search
5, Anonymous retrieval from the store.”

No! The concept i was writing about needs no third party storage, the retry buffer storage is on the sending client device, managed by an embedded MTA. Period! 🙂

This device (pc / smartphone / tablet / regular mail server with additional tor routing milter) runs an own embedded email server (if it is not a MTA, milter for existing MTAs) who buffers outgoing mail like every MTA does and retries sending until a timeout is reached, like every MTA does. This embedded MTA uses only the tor path, directly hidden server to hidden server with STARTTLS, if the remote hidden server name for an email address was retrieved by DNS and the client told the embedded server so.

This setup solves not a single “future encryption” problem, it only does double encryption in transit and this way it would reduce sniffable email metadata in transit to zero. Storage encryption can be done on local device storage level. All otherwise unencrypted mails sent this way client to client via tor and starttls are than locally unencrypted searchable like every other plain text email received on the “plain old mail path”.

If you optionally use additional email encryption you have the same as now, but with an additional “no metadata” feature.

Such an embedded TOR routing aware proxy MTA could recycle a lot of the Ricochet source code. Small open source mail proxies already exist (av / spam filtering mostly).

It is absolutly possible to make email more sniffing secure this way without reinventing a lot of wheels. We would just insert a secure direct p2p transport shortcut into the otherwise untouched SMTP/STARTTLS logic. No additional RFCs needed. 🙂

Ron Bregloch • November 13, 2015 4:31 PM

@ Not Over Yet • November 13, 2015 6:05 AM

E-fail sucks balls and leaks far too much meta-data….snippets….snippets….Pond consists of users and servers. Servers exist in order to provide availability by accepting messages for a user while that user may be offline. Servers may be freely chosen by users and each user may have their own server if they wish.

I think the problem is anonymity rests sorely on adoptability. In a successful anonymous system, with every user increase, the deniability of the payload must increase; opposite of how facebook and google works with user ups. Therefore, it’s most ideal to package said techs into easily deployable fire & forget devices (with auto updates), along with clever marketing e.g. riding the Snowden wave. But such must be made, sold, and shipped from an anonymous country, anonymous money, and trust in such anonymous sources; I’m not suggest doing anything illegal but something e.g. a Glen Greenweld stamp of approval would sell.

Ron Bregloch • November 13, 2015 4:46 PM

@ Name

So this is all I can contribute to the conversation:
If you’re worrying about the NSA entering your house via wire/fiber/wifi (you are, right?), then get an air-gapped internet-only machine. It’s how you do security these days. Cheaper but Harder is Stupid And Wrong, Less Cheap but Easy is the only safe, therefore correct, route. Don’t sweat, spend instead….snippets….snippets….As for routers etc, I don’t know enough to comment, unfortunately, except don’t buy American, Chinsee or Russian if you don’t have to.

minitel is that you

Dalton • November 13, 2015 5:50 PM

Nick P, that link was bad. I guess you meant to include this link to Ptacek’s blog.

There are some weird arguments. “Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.” Yes, because .ly is the domain for Libya and therefore not the domain to use if you distrust Libya. And as I recall, they didn’t use TLS in the early days… during which Gaddafi was still in power. So he did effectively control bit.ly.

Many of the existing problems like large keys and difficult deployment can be fixed (standardize Curve25519, write user-friendly software).

“Government-controlled PKI” is a valid concern, though I’d say any form of automatic encryption needs to involve DNS in some way (some other protocol like DNSCurve would be fine too). In the bootstrapping phase when all you have is a domain name, this type of PKI is helpful. We don’t actually need to trust it for all cases. You can explicitly configure public keys for top-level domains (like your own country’s) and lower domains, or cache them after first use, when you want extra security.

Anyway, we shouldn’t wait around for a perfect solution. Some of this technology already exists, and people just need the motivation to configure it. (Is the NSA enough motivation? I hope we don’t need to wait for Anonymous or some such group to run a large-scale email sniffing attack.) Some of it wouldn’t be too hard to code. Maybe once people view plaintext email transmission as negligence, as publication, we’ll get a critical mass of people ready to design the actually-good fully-end-to-end version of email security.

Nick P • November 13, 2015 7:56 PM

@ Dalton

Good catch: must have been juggling too much copy and paste haha. Far as the article, it’s a mixed bag of claims, yeah, but it’s Ptacek…

The main point I highlighted here was government control with me mentioning the weak crypto and lack of browser-side protection. I think the government-control and subversion is among the most important if Five Eyes etc are in the threat model. People worried about governments switch to something they control. Huh?

“Anyway, we shouldn’t wait around for a perfect solution. ”

Everyone’s favorite strawman. Nobody saying wait for a perfect solution. I’m saying that people wanting to protect their traffic from governments using crypto might not want a solution that semi-protects their traffic with weak crypto that governments control. It’s like it’s solving the government’s problem instead of ours. 😉

Grauhut • November 13, 2015 11:08 PM

@Nick: “I’m saying that people wanting to protect their traffic from governments using crypto might not want a solution that semi-protects their traffic with weak crypto that governments control.”

I would like to say if everything is encrypted, even spam, than this would make us more secure, because the Snoopers family is imho not yet able to decode every crypto crap in real time while sniffing.

They have to capture and decode everything offline then and that means more energy consumption and investments.

Cost is a useful resistor. 😉

Roy • November 13, 2015 11:42 PM

@Bruce: Do you think that something like the Dark Internet Mail Environment (DIME) is a wasted effort then?

Paul • November 14, 2015 4:30 AM

Daniel • November 13, 2015 11:49 AM
@Paul Dodd
“There are off-lime messages”
Then functionally how is it any different than e-mail? It seems like word games
now.

Never said they are different. An anonymous system obfuscate look up service, i.e. dns and metadata, to protect its users from privy eyes in transit, but it must also protect users from privying each other’s physical locations via lookups. It’s like posting to a private forum hosting on ToR. The forum itself is a store and forward server, it just doesn’t do push, but once you leave a message, it’s there, you can leave it encrypted too, but the recipient must receive the keys, in advance or retrospect, thru a secret side channel, or say another forum.

Dalton • November 14, 2015 8:46 AM

Nick P,

“Anyway, we shouldn’t wait around for a perfect solution. ”
Everyone’s favorite strawman. Nobody saying wait for a perfect solution.

Sure, I could have said it better. We shouldn’t be waiting for anything. We need to do something now and we have a decent enough starting point that’s even been standardized.

I’m saying that people wanting to protect their traffic from governments using crypto might not want a solution that semi-protects their traffic with weak crypto that governments control. It’s like it’s solving the government’s problem instead of ours. 😉

I don’t see how. Right now, we’re just giving them all our mail. We can start with an OK solution and then work toward end-to-end security (individual keys, endpoint hardening, alternate trust models).

Which government, by the way? The TLDs are operated by different governments (or non-governmental entities). The US government may be able to publish a fake key for .de, but such an attack is not subtle: DNSSEC doesn’t have non-repudiability, meaning someone’s log file could have proof of such an attack. Bruce has called the NSA very risk-averse, which is to say they generally avoid attacks for which they could be caught. And if DNSSEC lookups happen over Tor, a narrowly targeted attack would be extremely difficult. (Similarly, mail delivery over Tor makes traffic analysis much more difficult and should be easier to deploy than a “proper” mixer like Mixminion.)

DANE with DNSSEC is only one way to let people learn of a certificate. It’s not really “weak”; rather, people are giving up some DNS security in the interest of performance and data size. The actual TLS cert can be as strong as desired, can be signed and published via other means in parallel (e.g. CAs with certificate transparency), and the TLS can use any mutually negotiated algorithms. And DNSSEC can be done with larger keys until curve25519-DNSSEC or suchlike is usable.

CallMeLateForSupper • November 14, 2015 9:31 AM

@Bruce “I have recently come to the conclusion that e-mail is fundamentally unsecurable.”

M__D!! Are you saying that pasting encrypted-to-ASCII into a Gmail message body doesn’t work? And that copying encrypted-to-ASCII, saving to a file, then decrypting…. this doesn’t work either?! I feel so horribly deceived.

But seriously… I suspect you’re referring to e-mail ON A PHONE. I could get behind that; I don’t know how anyone gets anything useful done on a phone (other than talk).

Paul Koning • November 14, 2015 10:52 AM

This is silly. Usability problems are fixable. GPG is a fine email encryption tool; if the UI needs work that’s just a matter of some good programmers doing good work.

To apply the phrase “fundamentally unsecurable” makes no sense to me.

Dirk Praet • November 14, 2015 11:24 AM

@ Not Over Yet

These two programs (Pond and Ricochet below) should be funded heartily by someone who cares about privacy as a serious alternative to e-fail.

The Pond client is already part of my TAILS Candy package. So is the new Tor Messenger beta. Ricochet will be included as soon as it can use the TAILS Tor instance instead of the one that comes with it, thus tunelling Tor over Tor, which is not really what you want.

Sancho_P • November 14, 2015 6:20 PM

@Grauhut ”… if everything is encrypted, even spam, …”

After Snowden, some friends started attaching a file “delete.me” (a freshly created, empty 500kB TC volume) to each of their email, in the signature saying something like “please delete the unused attachment”.
… Then we realized that we will pay for their data center …

-> re your ”Cost is a useful resistor. ;)”

G • November 14, 2015 11:38 PM

@ Dirk Praet

The Pond client is already part of my TAILS Candy package. So is the new Tor Messenger beta. Ricochet will be included as soon as it can use the TAILS Tor instance instead of the one that comes with it, thus tunelling Tor over Tor, which is not really what you want.

Not sure if you want to go against its own advise:

Dear God, please don’t use Pond for anything real yet. I’ve hammered out nearly 20K lines of code that have never been reviewed. Unless you’re looking to experiment you should go use something that actually works.

and here:

Pond seeks to prevent leaking traffic information against everyone except a global passive attacker.

Bruce Schneier • November 14, 2015 11:50 PM

“That seems wrong. Fundamentally and from a user’s point of view, emails are arbitrary text data with an arbitrary text subject you can send and receive asynchronously. Everything else is implementation details.

“There is nothing making this fundamentally harder to secure than instant messages, it may be even easier thanks to the relaxed synchronicity requirement.”

E-mail isn’t simply messages going back and forth. If it were, encryption wouldn’t be a problem. (See OTR, or Signal, or any good usable encryption system for messages going back and forth.) E-mail is a messaging system, yes, but it’s also a scheduling system, a task management system, an information archival system, and a whole lot of other things besides. (Personally, I manage much of my life on e-mail.) Plus, it doesn’t have the easy duplex capabilities that other messaging systems have, and it has to work when the sender and receiver are separated in time. Put all of that together, and you get a system that’s very hard to secure in a way that maintains functionality.

Eugene • November 15, 2015 12:44 AM

Have you tried Pandor (Chrome) vs Mailvelope? [BTW Pandor does not intercept as per dev]! It integrates exceptionally well with Gmail, it’s easy as pie — encrypts –> send <–decrypts. May I ask your opinion?
What about RetroShare (Cross-platform)
Wickr vs Signal?

Hector • November 15, 2015 5:43 AM

Back to matter of semantics. Messaging systems nowadays do a lot more than just messaging too. 😉

Dirk Praet • November 15, 2015 6:56 AM

@ G

Re. Pond

Not sure if you want to go against its own advise

As usual, what you use depends on your threat model. Messengers like Pond and Ricochet are emerging applications that can only be improved if enough people are willing to test and audit them. Jake Appelbaum seems to be a Pond fan too, which is enough to draw my attention.

Danel • November 15, 2015 2:12 PM

Thanks Bruce for this follow-up.

I spent much of the morning ruminating on the issue and now I’m not so sure that my initial assessment that e-mail was better than IM is correct. It seems to me that this is the fundamental issue: The advantage of asynchronous communication is that the parties can be separated in time and space. But this creates a problem because it means that somewhere the message has to be stored by a third party. In this sense the e-mail provider works something like a bank credit card–it’s an intermediary. And wherever there is an intermediary there is room for MITM attacks (in endless variety). There is an intermediary problem with IM too but the attacker is constrained by the necessity of a real time attack.

So in the big picture the reality is that what constrains me constrains my attacker (real time) and what conveniences me conveniences my attacker (storage). The question then if one is facing an attacker like the NSA which is the better option. And it seems to me the better option might just be IM. The reason is that when the NSA can attack at leisure the NSA can take advantage of resource asymmetry. But when the NSA is constrained by a real time attack their resource asymmetry shrinks because there is only so many resources they can bring to bear at any moment.

E-mail storage, then, is just another example of my constant carping about content retention rules and regulations. By refusing to accept meaningful restrains on content retention the USA is forcing players to become more agile in order to level the playing field. And that agility is coming to bite the NSA back in the butt.

rgaff • November 15, 2015 2:35 PM

“(Personally, I manage much of my life on e-mail.)”

Thus, most every detail of your life can and will be held against you in a court of law. You might as well just register every passing thought through your brain directly with your local police, just in case they find a way to match it up with some kind of crime… After all, you do commit 3 felonies per day like every other American, even though you think you’re a “law abiding” citizen.

Clive Robinson • November 15, 2015 5:02 PM

@ Danel,

So in the big picture the reality is that what constrains me constrains my attacker (real time) and what conveniences me conveniences my attacker (storage).

I suspect you are thinking more of traffic content than traffic analysis.

The likes of the NSA and GCHQ are actually less interested in traffic content than they are in traffic analysis.

The traffic analysis is carried out on two parts, observation of the traffic flow or routing and any message metadata.

If you remove the traffic store then not only do the two parties have to be online at the same time, they also have to be in direct contact with each other which usually means a low latency bidirectional traffic flow which makes traffic analysis much easier even if the metadata is also obscured.

It’s this aspect that makes ToR in it’s current state so dangerous to use, because the FiveEyes sit astride the “choke points” and that in effect makes them omnipresent.

If however the two parties communicate via several third party stores with high latency, then even though the FiveEyes are omnipresent the traffic sinks below the noise threshold on a properly designed mix network (which ToR is not). The two parties are thus disconnected from each other both in traffic flow and meta data.

This moves the issue to the third party stores and their trustworthy ness. If the mix network used has sufficient latency and no metadata is attached to the encrypted file –message body– other than an encrypted tag, and the files are “constant size” then there is little for the stores to give away to the likes of the NSA, even with 100% cooperation.

Paul • November 15, 2015 6:28 PM

@ Clive Robinson
>The likes of the NSA and GCHQ are actually less interested in traffic content

than they are in traffic analysis.
The traffic analysis is carried out on two parts, observation of the traffic
flow or routing and any message metadata.


This is where I’m confused. If by traffic analysis you meant the message (or email) content is unexamined, then what makes a case for attack prevention? e.g. if and when Alice texted Bob to perform unnamed illegal activity, nothing in the traffic flow or metadata will ring alarm. The “message” itself is in traffic content.

Daniel • November 15, 2015 7:48 PM

@Clive,

Yes, in the sense you mean it I was thinking of traffic content rather than traffic analysis.

It goes back to threat analysis. Do I care if an attacker knows my metadata? In some cases I might care more about the metadata than the message content itself and in other cases I don’t. It depends on the context.

To come back to Bruce’s point about the inherent insecurity of e-mail, I am beginning to think he’s right. But that’s because any form on communication that can in some way be intercepted is inherently insecure. The only really truly secure communication I can have is my own thoughts and if one believes in an omnipresent god or various truth serums then maybe those aren’t even secure.

Clive Robinson • November 15, 2015 8:39 PM

@ Paul,

e.g. if and when Alice texted Bob to perform unnamed illegal activity, nothing in the traffic flow or metadata will ring alarm.

Actually the flow, quantity and delays on response of traffic often tell you more than the message contents.

A simple example was the lead up to the first gulf war. Whilst journalists were trying to get info out of their “unnamed sources” and failing miserably, the pizza delivery boys knew fairly exactly what the state of play was due to the changing patterns in the pizza orders.

It’s the same with all other forms of communications, by seeing the change in frequency, the message sizes, and the response times between the parties, you get nearly everything about the real state of “battle readiness” from an unwary opponent or enemy. The changes say more than the content does.

During the Second World World war the BBC used to read out “messages for our friends” after the news. These messages were meaningless phrases such as “The sun set in a blue sky”, they only had meaning as pre-aranged messages which were effectively “go/no-go” messages for prearanged activities or validation messages to prove identification etc. The main idea was to always have about the same number of messages after each news broadcast, many of which were just place holding or null padding so the German Signals Intelligence derived no meaning from the quantity of messages, and were thus not tipped off to an upcoming hostility.

It was a version of a “Fleet Broadcast System” where many encrypted messages are sent, but without indicators and always of the same length. Similarly “Number Stations” and even some keyed radio sonoids.

There are even multiple “path delay” transmitter systems where four or five widely geographicaly spaced transmitters send out apparently totaly random high speed codes. However in one place the path delays on the signals will when the signals mix produce a non random signal… It’s kind of like GPS in nature.

In all cases it is assumed the enemy can hear the messages but derive no intelligence from them because they are missing required information to sort the wheat from the chafe.

Another asspect of traffic analysis is “building up networks” of who is talking to who. If intelligence is known on some parties then infrences can be made about unknown parties simply based on contact and frequency of contact.

One of the important things to remember is that traffic analysis has minimal time delays involved where as decrypting message text or unobscuring meta data takes time, often sufficient time that the attack is over long before plaintext is obtained.

Wael • November 15, 2015 11:02 PM

@Clive Robinson, @Paul,

There are even multiple “path delay” transmitter systems where four or five widely geographicaly spaced transmitters send out apparently totaly random high speed codes. However in one place the path delays on the signals will when the signals mix produce a non random signal… It’s kind of like GPS in nature.

That’s a very interesting topic. A lot can be said about it 😉 gives me some ideas too! I would say such a system is relatively easy for an adversary to defeat by reconstructing the signal through some correlation and statistical methods. The “search space” isn’t huge, and depending on the nature of the signal could be bound within a wavelength of “key space”.

Dirk Praet • November 16, 2015 5:12 AM

@ Clive

During the Second World World war the BBC used to read out “messages for our friends” after the news. These messages were meaningless phrases such as “The sun set in a blue sky”

Les sanglots longs des violons de l’automne blessent mon coeur d’une langueur monotone.

dittybopper • November 16, 2015 10:21 AM

The NSA is interested in both traffic analysis, and in reading the traffic. TA is used more when you can’t read the traffic itself, but it’s a poor cousin to actually being able to read the messages.

For mass surveillance, reading the messages isn’t practical. But if you ever come to their attention, they will make every effort, cryptological and/or “practical” to read your messages. The only way to minimize that danger is to never, ever have plaintext on a computerized device.

It’s indeed ironic that in this day and age, a pencil and piece of paper is more high security than anything with a microchip.

Paul • November 16, 2015 7:21 PM

@ Clive Robinson, Wael, Dirk Praet, dittybopper

Clive Robinson wrote:
One of the important things to remember is that traffic analysis has minimal
time delays involved where as decrypting message text or unobscuring meta data
takes time, often sufficient time that the attack is over long before plaintext
is obtained.

Thanks for the explanations. I don’t know much about signals but it seems to me there are two sets going on here. Messages, or encrypted payloads, and a white drop. When there isn’t enough background noise, messengers must fill in. But as a cost creating white noise gives away messengers to be known by parties interested, like a choke points. As in the case of ToR, these choke points are known to all thus some deem it ‘fair game’. So little did I know, this actually plays out like a spy games predate iron curtains.

But, of course, ordinary folks like us we don’t care about sending out signals. It isn’t a life or death situation whether our friends get the “message” (e.g. nites out at the gentleman’s club). To the ordinary folks, it is more a matter of privacy and the many messages are just as simple as whats, or who’s, cooking for dinner. So I suspect the solution is much simpler.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.