The Dream of Usable Email Encryption Is Still a Work in Progress
motherboard.vice.com
motherboard.vice.com
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.
You just need to keep a copy offline in case the device is stolen.
That is a ridiculous link IMO.
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_operatin...
Yubico should release an Bluetooth LE Smartcard and then it should be possible on IPhone.
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.
So, no, this is not a good argument.
The comment I replied to mentions the iPhone, but made the blanket statement "Your mobile..." plus the article I linked to addresses multiple mobile OSs.
It would be helpful to explicitly state which make and model smartphones you believe are not susceptible to baseband threats. I think Blackphone has also integrated countermeasures but information on this topic is pretty sparse.
Now if we can forget the comparison between smartphones and computers, it would be great to know exactly which smartphones are a good choice for users of encrypted email. I'm on Android now only because it easy enough to root and use without any Google services (I prefer to self-host and use F-Droid for apps). I don't particularly like Android but it is the 'lesser of two evils' for now.
If I can do the same with an iPhone and never have an account with Apple I would definitely be interested as the iPhone hardware seems pretty good.
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...
* 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.
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.
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?
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.
Banks, insurance companies, pension funds, the revenue service, the local municipal government; they all expect you to frequently log on to their portals, and look at their digital correspondence addressed to you there. Some do send a notification e-mail stating that 'a message is waiting for you', but you never know if that message is actually important or merely trivial noise. They have declared e-mail dead.
I abhor this situation, because with e-mail (and coincidentally, old-fashioned paper mail) all correspondence addressed to me comes to me in a single inbox, where I can archive and backup important stuff. I really wish I had the option to simply upload my GPG public key to these portals so that all these phony inboxes simply mailed me my correspondence encrypted!
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.
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.)
Avoid them? They are their most profitable kind of ads...
https://support.google.com/adwordspolicy/answer/6210602
In any case, if you see an ad that you find unacceptable, please report it.
It's pretty common for corporations to use their own root certificate so they can snoop your HTTPS, one would have to assume security officers wouldn't be really interested in individual employees encrypting their mail at the MUA and the company losing visibility on outbound messages.
The thing I never got though, is why signing messages never really caught on. You'd think banks and financial service providers would have an interest here. Maybe they don't want to deal with the support headache.
Conversely....I can see the argument not to. Uploading 50,000 1-character name mismatch to bank encryption keys would definitely happen.
Few if any big companies are going to be sending you GPG/PGP encrypted or signed email or be willfully receiving it. Take the Fortune 1000 off the list of potential secure email users and you've got a large portion of the professional class who won't know how to use this technology. I think that's a barrier to adoption.
DKIM is much more a spam fighting tool than a substitute for E2E authenticity validation.
https://gmail.googleblog.com/2016/02/making-email-safer-for-... https://openbit.eu/projekte/trusted-internet-services/
It has instructions for all major operating systems.
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
[2] https://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abst...
I use Enigmail to send encrypted email on a daily basis. It couldn't be much easier than it is already.
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).
I'd worked on a proof of concept that would have all three of the above features using a DHT for delivery, relying on collisions for addressing, so that targets overlap, but a given target could only decrypt messages actually to them... the down side is it would be possible to send MANY messages to a target, so many that the system would be brought to a crawl and effectively useless.