7 ms·
The Dream of Usable Email Encryption Is Still a Work in Progress
- nickik 11y agoI think keybase has the best attempt at a solution. They solve two fundamental problems. 1. Identity. its the sum of your online presence. 2. Insecure devices. In keybase devices have unique keys and can can be revoked when lost I have been trying Protonmail, they have been deploying gpg in browser and apps. The interface is nice and I would have no problem recommending it to my parents. The problem is that it currently only works with other Protonmail users. Once they allow adding public keys for contacts and searching keyservers/keybase it will be quite nice and useful. They have no solution for the key security on the mobile phone. I personally dont want my key on my phone. I would really like to see a product that interfaces keybase and protonmail. Nicely designed apps and webinterface that all have different keys. Directly integrated with my social media contacts. Thanks to everybody working these problems.
- cm2187 11y agoYour mobile should be one of the safest places to store a key. Think of the work it takes the FBI to open an iphone. You have a closed, encrypted device which runs app whitelisting. Nothing is perfect but compared to a desktop computer it is a safe vs a shoe box. You just need to keep a copy offline in case the device is stolen.
- tdkl 11y agoBecause "mobile" somehow means "iphone" eh ?
- cm2187 11y agoGiven their market share this is not a ridiculous link.
- kuschku 11y agoWhich is in Europe at 14%? That is a ridiculous link IMO.
- CrystalGamma 11y agoDepends on where. Here in Germany nobody in my family and only one of my coworkers (AFAIK) has an iPhone, and only two have iPads, while basically everyone I know has an Android device.
- nickik 11y agoTheir is a huge difference between a phone that is encrypted and turned off and a phone that is turned on, is constantly moving threw unkown wifi networks, has tons of app with to many permissions on it and can auto upgrades most of them.
- tombrossman 11y ago> "Your mobile should be one of the safest places to store a key." I have to take issue with this. I think your mobile is probably one of the least secure places to store a key, due to the 'baseband problem'[0]. Your mobile in its normal (powered-on and connected to a network) state is probably less secure than using a fresh un-patched install of Windows XP today. I mean the original version of XP, pre-SP1 with the firewall disabled. This is why people say to choose a device without a mobile radio chip at all for secure communication, such as an iPod Touch[1]. I'd really like to have PGP/GPG encrypted emails on my mobile and I had it tested and working for a little while before looking into the baseband issue. I've since revoked the keys I used for that test and I am resigned to the fact that I will not be able to securely use encrypted email on my mobile phone for the foreseeable future. I keep my keys off the phone now, along with an unpublished email address at a different domain which is to be used for account recovery for those email accounts in use on the phone. [0]http://mobile.osnews.com/story.php/27416/The_second_operating_system_hiding_in_every_mobile_phone http://mobile.osnews.com/story.php/27416/The_second_operatin... [1]https://twitter.com/csoghoian/status/686035633949818881 https://twitter.com/csoghoian/status/686035633949818881
- nickik 11y agoOn Android you can use a Smartcard over NFC (K-9 Mail and OpenKeychain). Yubico should release an Bluetooth LE Smartcard and then it should be possible on IPhone.
- mindslight 11y agoThere are phones with separate application/baseband chips. I have a Samsung i9500 (one of the many models called "Galaxy S4"), which I believe is the most recent of such phones that can run Cyanogenmod. Also, I think most Apple devices are separated in such a manner as well? Of course there's likely still a whole collection of closed software that takes constant network connectivity for granted, and does who-knows-what. The Android code is open, but it seems like there won't be enough eyes looking at vulnerabilities to the vendor with regards to say the GApps suite. And making the choice of utility between Google Maps and K-9 mail, I picked Maps. It also doesn't help that phone models are so varied as to diffuse the interest in investigation/teardown/auditing.
- tracker1 11y agoI have to agree... I keep hoping that someone build something easier to use on top of keybase... (assuming keybase sticks to it's single purpose, and doesn't try to build it's own systems on top) It also makes sense to separate the public key aggregation from the services that use the keys, and the plugin systems that translate... it would be easy enough to create a browser plugin that exposes an API that can be used to encryptMessage or signMessage, where the plugin notified/asked the user.. and all the in-browser app will get is the encrypted message... same for decryptMessage and verifyMessage... Hmm...
- nickik 11y agoKeybase will be doing that. They already have Saltpack (saltpack.org). They want to first do the file system and then massenging.
- noobie 11y agoI use Keybase + Thunderbird + Enigmail. It's not the most user-friendly approach but honestly I think whoever is not willing to go the distance now doesn't really value encryption/their privacy and thus won't quite care when encryption is more usable/ mainstream.
- adrianN 11y agoI agree with you, but I think that we should try to make encryption something that you don't have to "do". HTTPS is widely used even by people who don't really care about their privacy, because it just happens automatically. I'm not sure whether it will ever be possible to do the same with e-mail, but I think it would be cool if all messages where encrypted and authenticated by default.
- Freak_NL 11y agoThe challenge here with authenticated end-to-end encryption, is that it depends on having the user's private key available. Whereas for HTTPS no secret knowledge factor belonging to the user is needed (unless you use client-side certificates). That simplifies matters quite a bit.
- chopin 11y agoThat's of course only possible with the (imho) broken CA system.
- XorNot 11y agoTrust would be a better problem to solve then encryption, at least initially. The big problem plenty of people have with email (and for me at least, the phone) is establishing who I'm actually talking to when dealing with a business. It would be really great if when my bank emailed me, the message was signed with the key they use on their website so we could seamlessly establish that it was really from them.
- Freak_NL 11y ago
- beardog 11y agoIts not email, but a "similar" protocol (similar in the way the user interacts with it) that is secure is Bitmessage(https://bitmessage.org/ https://bitmessage.org/)
- vmateixeira 11y agoIs there something that I'm missing here? Google and Yahoo are developing an encryption mechanism which will prevent themselves from reading users emails? I thought that was part of their business..
- ThePhysicist 11y agoI think they talk more about encryption of the e-mails during transport. Keeping e-mails encrypted on a server is doable and not very hard (Protonmail does this for exaple), but encrypting e-mails while they're in transit and go through some possibly untrusted mailservers is more challenging, because it usually requires asymmetric encryption e.g. via PGP. This in turn requires that the sender has access to a valid and trustworthy PGP key for all recipients of the e-mail. Distribution of these keys must be based on some form of trust, which in itself can be challenging to establish (hence services like Keybase). Also, while good solutions exist for using PGP in web- or desktop mail clients, usability is still not very good especially for people that don't have a technical background (in my opinion). I use PGP-based e-mail encryption a lot at work and I can say that there are still a lot of things to improve here.
- cm2187 11y agoThe article seems to be specifically about a PGP derivative.
- dineshp2 11y agoThat's right.Google and Yahoo won't be able to scan users' mail and deliver targeted ads anymore. Encrypted email will also prevent Google and Yahoo from extracting insights about users and it's safe to assume the management at these companies are not particularly excited about the prospect of encrypted email.
- newjersey 11y agoI thought the idea was that they derive more insight from bulk or other commercial mail which will continue to remain unencrypted (maybe signed?) than from personal emails. I imagine it is a hassle for Google to avoid ads in sensitive topics like "grandma fell from the roof" and "mr snugglepuff just got diagnosed with cancer". If person to person emails were encrypted, I'd think the emails from Target and Amazon would still not (is my argument flawed? It feels flawed but I can't put my finger on the flaw.)
- deleted 11y ago[deleted]
- dave2000 11y agoSurely the idea that all email providers/clients/services will all suddenly work together and solve the ui and technical problems inherent in PGP use is a bit of a dream, and in fact the answer is to just not attempt it and instead use encrypted im sessions which already exist.
- drakenot 11y agoI've been eagerly awaiting the release of this e2e plugin. However, I'm not holding my breath. Go take a look at GitHub repo[0]. The last commit was a merged pull request on Feb 24th and the commit before that was Jan 27th. [0] https://github.com/google/end-to-end/commits/master https://github.com/google/end-to-end/commits/master
- vu3rdd 11y agoThere is this nice guide: https://emailselfdefense.fsf.org/en/ https://emailselfdefense.fsf.org/en/ It has instructions for all major operating systems.
- nhf 11y agoThis guide is nice for people that are motivated, but a large chunk of users (probably the majority, but I have nothing to back that up except a guess) will only encrypt their emails when it's as frictionless as sending an unencrypted email. Encryption tends to be successful when it's baked in to the system (e.g., WhatsApp theoretically), a preset default (e.g., Android 5.x+ and iOS), or requires absolutely minimal effort (e.g., the HTTP -> HTTPS "switchover"). This has been a known issue for a pretty long time [1, 2]. [1] http://www.gaudior.net/alma/johnny.pdf http://www.gaudior.net/alma/johnny.pdf [2] https://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abstract.pdf https://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abst...
- dublinben 11y agoOnce you've set up Enigmail with your PGP key, it is as frictionless as sending unencrypted mail. I use Enigmail to send encrypted email on a daily basis. It couldn't be much easier than it is already.
- Bino 11y agoE2E encryption has a very long way to go. If PGP or S/MIME were the answer it would had successes (conquered the world) by now. I do appreciate the security advocates preaching PGP, but in all fairness it may be a lost cause. Some security is better than none and so we should applaud google and others' initiative to improve the encryption at the transport (SMTP protocol) level, without too much involvement of the end-user. And hope more will follow, whatever it may be. https://gmail.googleblog.com/2016/02/making-email-safer-for-you-posted-by.html https://gmail.googleblog.com/2016/02/making-email-safer-for-... https://openbit.eu/projekte/trusted-internet-services/ https://openbit.eu/projekte/trusted-internet-services/
- tptacek 11y agoBecause of the way technology adoption works, pushing for "some security" over "no security" is a good way to end up with "some security" (and, because attacks only get better, over the long run back to no security) forever.
- tptacek 11y agoAnother reasonable way to look at this situation is to conclude that trying to provide safely encrypted email is not a good idea. The protocol is, in this argument, simply too hostile to sound cryptography to reliably encrypt things. Instead, we should focus on: * Getting providers to safely engage TLS for MTA-MTA mail relaying, for instance by deploying key pinning. * Making existing non-seamless cryptography (PGP) functional enough that it can be used in exceptional cases. * Deploying new asynchronous encrypted messaging systems --- things like what Adam Langley was shooting for with Pond --- that were designed from the start with security in mind. Secure-by-default email would be nice to have, but it's not the only option. We could, instead, deprecate SMTP email.
- atmosx 11y ago> Making existing non-seamless cryptography (PGP) functional enough that it can be used in exceptional cases. Hm, I don't believe it's a technical problem, although it's a recurrent theme among techies. PGP is hard to explain to someone who didn't spend the time to digest certain concepts but installing GPGTools on your mac, generating a key and using it is not hard, nor complicated... You can even store the passphrase in the keychain. I believe that most people using email don't feel there's any added value in using GPG, that's all. This might change in the future, but we're not there yet.
- smt88 11y ago> Deploying new asynchronous encrypted messaging systems Couldn't Google, Microsoft, Yahoo, Apple, and any other large email providers at least agree to transparently use a different, secure protocol among themselves? It could be something open-source (perhaps Pond) that other providers could also choose to adopt. The mail-sending server could ping the recipient server, find out if it's a user of this new protocol or not, and then fall back to email if it doesn't receive the predetermined response. Even if that only means that only 80% of emails were encrypted on average, that would be an improvement, wouldn't it?
- yyin 11y agoI'd prefer to see decentralized email before "encrypted" email. Recipient runs qmail listening for connections on some personally chosen port from among 1000's of choices. She is also running a firewall such as pf. authpf might also be useful. Recipient tells sender her chosen port number and a personally chosen address to use. How does she do this? In person. Through the postal mail. Over the telephone. But _not_ over the Internet. Of course she does not have to use the same port and address for every sender. In addition to the potential randomness of the port, the address she chooses could be any string of legal characters up to 250 whatever in length. The approved sender runs qmail to connect to recpient's qmail and leaves a message on recpient's computer. No DNS. No "email provider". No POP3. How two users can discover each others' IP address and connect to each other through firewalls _without forwarding traffic through a third party server_ is left an as exercise for the reader. Chances are most users have used software that does this at one time or another, maybe without even knowing it. The methods have been around for decades. It works. Centralized DNS and the need for a "domain name" is not needed. Centralized "email providers" who store users' email are not needed. There are a number of disadvantages and limitations to this approach. Yes, I know what they are. But I have already tested this and it works so I'm biased. My opinion is that the _advantanges_ of "peer-to-peer", SMTP-to-SMTP email easily outweigh the disadvantages of store and forward and POP3 and make this a useful _alternative_ (not a replacement) system for centralized email. It's an _option_ users could have that would be quite useful. The status quo approach to email has become highly centralized in both the need for ICANN DNS and "email providers". Not to mention the commercialization of email and the need to have "permission" to be able to send mail "because of" the proliferation of spam. It's far too difficult for any user to control their own email under the current centralized system. Solution: Give users another system where they _can_ control their email. IMHO the centralization and protectionism of the current system (email is a business, but it doesn't need to be) is a bigger problem than lack of encryption. It's also what makes spamming viable. Everyone knows your email address or can get it easily enough. In many cases, that is not necessary. As it stands, email is concentrated in a limited number of locations (the servers of email providers), transferred over a few ports (25, etc.) and users are limited in the addresses they can use (commercially registered domainnames).
- Natanael_L 11y ago