Now that companies are rolling out 2-factor authentication, will there be companies that allow users to nominate their public key to be used in encrypting emails that the system sends them? This would help to drive adoption of email encryption in general and doesn’t really require a major impost on the part of the service provider.

What obstacles are holding this back?

Cost to implement?

Lack of demand?

Risk averse companies not wanting to be involved in legal / privacy implications?

Variety of encryption techniques?

All of the above?

From the users perspective it’d be just another ‘setting’ you configured. In addition to your email address, provide the URL to your public key or copy / paste it.

If you’ve got an examples of companies that currently do this please let me know.

Microsoft only *JUST* finished turning on TLS properly for its SMTP servers across all the hotmail, outlook.com etc properties… so I won’t hold my breath for a nice UI for user key management. Didn’t Mr PGP himself create Silent Circle? You’d think that would’ve had decent usability.

But PGP isn’t just about making your messages opaque – identity is important as well. I just don’t know how you’d scale the web of trust up to include all of the click-happy masses merrily entering their banking creds into obviously fake phishing sites – they’ll just happily accept any pubkey that’s thrown at them…

The real problem though is that SMTP, despite being the poster-child for what can be achieved with open standards and federated de-centralized architecture (can you imagine where we’d be if in 1982 we started off with this walled garden crap?), it’s desperately showing its age.

PGP needs to be engineered in properly (try doing HTML messages between Thunderbird & Outlook with their respective PGP plugins), and even with all the bolted-on stuff like DKIM, SPF, STARTTLS etc… the real problem for the security conscious (apart from all the plaintext flying about, which even Microsoft apparently struggles to solve) is that it’s basically impossible to obscure your communications from traffic analysis.

And if the whole planet knows who you’re talking to and when; how frequently; roughly how large messages are – and so on, then there are many infosec people who throw up their hands up and say it’s not worth fixing. In some parts of the world, this metadata can get you killed, they say…

Patrick Gray from http://risky.biz (confession: I listen to his podcasts on the drive home each Friday) has just started something called http://invisible.im/ – it’s a very interesting experiment that is trying to do everything “properly” to the extreme. P2P, anonymous, encrypted chat – they’re trying to build something robust enough for contacts to share things with journalists, for which E-mail & OpenPGP just isn’t good enough.

weharc

Cheers, thanks for the reply. I know what I was suggesting is really only half-arsed because it doesn’t prove the identity of the sender as you’ve pointed out, and all the meta-data is still in the clear. I just thought it might be a semi-useful step that obscuring (I won’t say securing) some of the contents of emails like that to make it just that little bit harder for people intercepting emails. I guess though there’s just as much chance for them to intercept the authentication to the server in the first place.

I guess the real problem is the cat is out of the bag as far as the prevalence of email infrastructure and then all the security concepts are bolted on later. Good point.

csirac2

There seems to be a big problem among infosec people that partial solutions aren’t worthy of consideration. That’s the real issue in getting this taken seriously – there’s a bunch of security experts saying PGP on E-mail isn’t good enough.

But now you’ve got me wondering if it’s worth making a GreaseMonkey-esque Chrome/FF extension that seamlessly makes PGP work properly with the big webmail providers… then I just remembered that latest Chrome requires your app to be installed from the Google Play store, damnit.

I wasn’t terribly comforted by their rebuttals to the common criticism that Browser JS is a shaky foundation to be implementing crypto on

weharc

the other problem with browser based stuff is the possibility of sneaking a JavaScript based keylogger into the page without the user realising. Now it’s getting into the realm of ultra-paranoid, and I’m erring on the side of those people who see security as an absolute I guess.