The Dream of Usable Email Encryption Is Still a Work in Progress(motherboard.vice.com)
motherboard.vice.com
The Dream of Usable Email Encryption Is Still a Work in Progress
https://motherboard.vice.com/read/google-yahoo-end-to-end-email-encryption-work-in-progress
57 comments
I 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...
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...
Keybase will be doing that. They already have Saltpack (saltpack.org). They want to first do the file system and then massenging.
Your 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.
You just need to keep a copy offline in case the device is stolen.
> "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_operatin...
[1]https://twitter.com/csoghoian/status/686035633949818881
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...
[1]https://twitter.com/csoghoian/status/686035633949818881
There 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.
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.
The iPhone baseband processor speaks a point-to-point USB-like protocol to the AP, and does not have access to secrets stored in the AP or the secure enclave. Secure applications on the phone have to assume that the cellular network is insecure already, so the colocated baseband processor doesn't much impact the threat model.
So, no, this is not a good argument.
So, no, this is not a good argument.
Not a good argument for the tiny fraction of smartphone users who happen to use iPhones, or not a good argument at all?
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.
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.
Modern iPhones are generally significantly more secure than modern Android phones, but so long as we're talking about (a) modern mobile devices (b) provided by Apple or Google, then I'm comfortable saying that all these devices are more secure than your computer --- which, for what it's worth, is littered with all sorts of little embedded doohickeys with code you can't see.
Okay good to know. Not sure who's downvoting you because this is useful info.
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.
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.
Basebands have not had full hardware access for quite some time now, due to their habit of being full of exploits that can be used to unlock the device. It's not just an iPhone thing.
On 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.
Yubico should release an Bluetooth LE Smartcard and then it should be possible on IPhone.
Their 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.
Because "mobile" somehow means "iphone" eh ?
Given their market share this is not a ridiculous link.
Depends 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.
Which is in Europe at 14%?
That is a ridiculous link IMO.
That is a ridiculous link IMO.
Another 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.
* 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.
> 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.
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.
> 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?
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?
I 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.
I 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.
The 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.
Trust 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.
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.
Unfortunately, banks (at least in The Netherlands) seem to favour a different solution altogether, which is not to send e-mails at all, but expect you to log on frequently on their on-line banking environment to look in your banking 'inbox' there.
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!
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!
That's of course only possible with the (imho) broken CA system.
Then we'll have to make it op-out. Honestly, I would love to have it working on my parents Thunderbird without any further popups. They have no idea and are regularly confused. Especially if the popup is in a language they don't understand.
Is 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..
That'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.
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 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.)
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.)
Google could place ads based on what the user was typing prior to sending, or reading reading post decryption. It would be no more intrusive than any website knowing what users are doing whilst surfing.
>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".
Avoid them? They are their most profitable kind of ads...
Avoid them? They are their most profitable kind of ads...
Maybe using signals there to serve ads elsewhere (i dont have any inside information)but ads on Gmail have certain restrictions.
https://support.google.com/adwordspolicy/answer/6210602
In any case, if you see an ad that you find unacceptable, please report it.
https://support.google.com/adwordspolicy/answer/6210602
In any case, if you see an ad that you find unacceptable, please report it.
That was also my thought all along while reading the article. They are pushing big on these personal assistants which will go completely blind with pgp. So it's like trusting an ad company to develop an ad blocker.
I 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.
The article seems to be specifically about a PGP derivative.
It's not just Google and Yahoo, it's the other email providers, i.e. Your employer.
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.
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.
That one constantly perplexes me. The GPG signature, or X.509 even, means nothing in the message. But if you go to the trouble of putting it in there, then I can actually run checks.
Conversely....I can see the argument not to. Uploading 50,000 1-character name mismatch to bank encryption keys would definitely happen.
Conversely....I can see the argument not to. Uploading 50,000 1-character name mismatch to bank encryption keys would definitely happen.
Employers that care about this will simply ban origination of E2E secure messages from their networks. Plenty of large companies already ban web mail providers entirely, for similar reasons. So this isn't much of a factor in adoption of encrypted mail.
Right but my point is, big corporations are actively opposed to E2E secure messages and that's a barrier to adoption.
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.
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.
Most mail is now signed with DKIM.
Great, if you trust your middle man email provider to get this right and want no visibility on the message's authenticity.
DKIM is much more a spam fighting tool than a substitute for E2E authenticity validation.
DKIM is much more a spam fighting tool than a substitute for E2E authenticity validation.
If you don't trust your send gateway then you are without a doubt hosed anyway, as they can just strip your signature anyway (or, replace it with one linked to a key they generated in your name on the fly). Yes, if your correspondant is super on the ball and notices that you didn't sign/encrypt this specific message, maybe you win. But if I were a bad MITM I'd just put "Sent from my iPhone" at the bottom and there is the plausible explanation.
E2E 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-... https://openbit.eu/projekte/trusted-internet-services/
https://gmail.googleblog.com/2016/02/making-email-safer-for-... https://openbit.eu/projekte/trusted-internet-services/
Because 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.
I'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
[0] https://github.com/google/end-to-end/commits/master
Surely 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.
Its not email, but a "similar" protocol (similar in the way the user interacts with it) that is secure is Bitmessage(https://bitmessage.org/)
There is this nice guide: https://emailselfdefense.fsf.org/en/
It has instructions for all major operating systems.
It has instructions for all major operating systems.
This 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
[2] https://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abst...
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...
Once 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.
I use Enigmail to send encrypted email on a daily basis. It couldn't be much easier than it is already.
[deleted]
I'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).
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).
It's just the nature of decentralized + secure + anonymous (at least to the transport layer) ... you can't realistically have all three without being open to effectively a DDOS, poisoning the system as a whole.
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.
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.
Look at I2P's Bote mail
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.