Improved Authentication for Email Encryption and Security(protonmail.com)
protonmail.com
Improved Authentication for Email Encryption and Security
https://protonmail.com/blog/encrypted_email_authentication/
76 comments
> With also using ProtonMail, I would expect to be on a government list of some sort.
Are you aware what kind of idea you are circulating here? It's the kind of idea citizens in totalitarian states would circulate, probably even in the hope to score points from their dictator, for participating in instilling "order".
Dude, wake up. This is sick.
Are you aware what kind of idea you are circulating here? It's the kind of idea citizens in totalitarian states would circulate, probably even in the hope to score points from their dictator, for participating in instilling "order".
Dude, wake up. This is sick.
In a world where both large Internet companies and governments collect meta data, possible collect more than meta data, set up fake cell towers, etc., I think it is naive to not think that they are also collecting statistics on the use of encryption.
Perhaps you misunderstood me?
Perhaps you misunderstood me?
You're basically suggesting that using tools that strengthen democracy is to our disadvantage, because it does not please the government, and that we should therefor not use them to defend our rights. Basically, we should accept being manipulated by fear.
There is a difference between pointing out how surveillance works and saying it's good.
I use ProtonMail. I'm aware that puts me on a list in all likelihood. Still doing it however. I'm of the opinion that more encrypted private communication between citizens can only be a good thing for freedom even if it enables a few criminals. And I have to do my part.
Our government already cares very deeply about this sort of thing. It is important to read more than just the headlines involving something absurd stated by tech-illiterate politicians.
http://csrc.nist.gov/publications/PubsSPs.html
https://www.iad.gov/iad/index.cfm
http://csrc.nist.gov/publications/PubsSPs.html
https://www.iad.gov/iad/index.cfm
"What our government should do is a moon-shot level of effort to promote strong encryption and very robust digital infrastructure."
They did. It was called the Computer Security Initiative. It was the culmination of efforts starting with Anderson Report that collectively invented INFOSEC and deployed high-assurance versions. Early releases were secure messaging, the BLACKER VPN, MLS endpoints, private databases, and so on. Industry ignored it in favor of cheapest, fanciest products with features moving at explosive pace. Congress's (or DOD's) COTS mandate and NSA's MISSI initiative finished it off by reducing government contracts for high-security product.
So, it's been done here before. It would work again. Just no will to do it on top esp with Microsoft and IBM's lobbying. ;) At least the papers on requirements and methods for achieving that were all published. Some still use the methods in commercial sector and CompSci. The first, secure systems are still available comnercially on not-so-secure hardware (i.e. Intel). Just almost no uptake in FOSS for such methods despite a labor advantage.
They did. It was called the Computer Security Initiative. It was the culmination of efforts starting with Anderson Report that collectively invented INFOSEC and deployed high-assurance versions. Early releases were secure messaging, the BLACKER VPN, MLS endpoints, private databases, and so on. Industry ignored it in favor of cheapest, fanciest products with features moving at explosive pace. Congress's (or DOD's) COTS mandate and NSA's MISSI initiative finished it off by reducing government contracts for high-security product.
So, it's been done here before. It would work again. Just no will to do it on top esp with Microsoft and IBM's lobbying. ;) At least the papers on requirements and methods for achieving that were all published. Some still use the methods in commercial sector and CompSci. The first, secure systems are still available comnercially on not-so-secure hardware (i.e. Intel). Just almost no uptake in FOSS for such methods despite a labor advantage.
The failure of USG to fund secure alternatives to existing computer hardware and software is a black mark. I do not think it will be judged well by future historians of this era.
"At least the papers on requirements and methods for achieving that were all published."
Hi there! Ive seen you post on these before; do you have a collection of links or references to papers an infosec engineer interested in this should read? Ty
Hi there! Ive seen you post on these before; do you have a collection of links or references to papers an infosec engineer interested in this should read? Ty
Send me an email at address in my profile. Ill send them to you as I dig them out.
[deleted]
We had this at Lavaboom (German encrypted email, bankrupt) 2 years ago. Our designer came up with this idea, I initially wanted to implement the classic 2 password design. The tricky bits are (1) explaining to the users that they can't reset their password and (2) supporting users who opt for manual key management (e.g. I own [email protected] and I want to move from Google Apps + GPGtools to Lavaboom/Protonmail/etc).
https://github.com/lavab
our (brilliant) designer http://www.felixvonlooz.com/
https://github.com/lavab
our (brilliant) designer http://www.felixvonlooz.com/
>The tricky bits are (1) explaining to the users that they can't reset their password
So that's interesting, because as I understand it ProntonMail does allow users to reset their password using a recovery email, although the feature can be disabled in the settings.
So that's interesting, because as I understand it ProntonMail does allow users to reset their password using a recovery email, although the feature can be disabled in the settings.
If a user resets their single password or encryption password, they lose access to their previous e-mail. This is because what essentially happens is that a new PGP keypair is generated and the Secret Key is encrypted with the new password. Since we do not have their old, lost, password we cannot access their secret key to decrypt the e-mails (and subsequently re-encrypt them with the new Public Key).
An alternative is to generate a bunch of recovery keys, encrypt the PGP key pair with each of them, and store the result (but not the recovery keys). If you go for the 1 password solution this should be a no brainer, but still way too complicated for the utterly non-technical user (so most of them).
[deleted]
With as many SHA1/SHA256 etc ASICs, hopefully they change some of the hashing parameters to make this secure. The downside is the server has to match the hashing iterations.
Considering how emails can stay in service storage for decades , (even longer if archived by spies, etc), their security is now reaching the requirements of data on Hard Drives.
Considering how emails can stay in service storage for decades , (even longer if archived by spies, etc), their security is now reaching the requirements of data on Hard Drives.
So how does one migrate from the two password to the one?
I like the idea of protonmail, but since they made it incompatible with normal public key encrypted mail it's pretty useless for many of us, unfortunately...
Looks like it's over in the settings; just under Change Password is Switch to One-Password Mode.
PGP is quite difficult to use by most people, and it doesn't even support forward secrecy, which is a huge weakness. It will never be used by more than a core group of highly technical, which is maybe less than 0.01% of the population.
If we're to push end-to-end encryption to the masses, then we ought to try to get forward secrecy in it, and it should be quite invisible to the user.
That's not to say that ProtonMail is getting it right, but it's at least one of the few that are striving to move in that direction.
Relevant post from Moxie from Open Whisper Systems:
https://moxie.org/blog/gpg-and-me/
If we're to push end-to-end encryption to the masses, then we ought to try to get forward secrecy in it, and it should be quite invisible to the user.
That's not to say that ProtonMail is getting it right, but it's at least one of the few that are striving to move in that direction.
Relevant post from Moxie from Open Whisper Systems:
https://moxie.org/blog/gpg-and-me/
Perfect is the enemy of good. Mass adoption of PGP would made the work of hackers and spy agencies orders of magnitude harder.
Moxie writes from a personal perspective and you'll notice he never claims to have something better in hand. His Signal still lacks utterly basic functionality provided by PGP, most important among them the ability to transmit arbitrary attachments (Signal only supports an undisclosed list of media attachments) but also including the ability to retain your messages long term in a particular location. Meanwhile, many of the tradeoffs made to make Signal easy could be made using PGP: Automatic generation of keys; centralized key repo; centralized mapping of keys to contact points (email/phone); trust by default.
Moxie writes from a personal perspective and you'll notice he never claims to have something better in hand. His Signal still lacks utterly basic functionality provided by PGP, most important among them the ability to transmit arbitrary attachments (Signal only supports an undisclosed list of media attachments) but also including the ability to retain your messages long term in a particular location. Meanwhile, many of the tradeoffs made to make Signal easy could be made using PGP: Automatic generation of keys; centralized key repo; centralized mapping of keys to contact points (email/phone); trust by default.
Email is becoming obsolete, and today's generations are using messaging apps which also provide PFS (fwd secrecy). PGP et. al. don't provide any of that.
Today's messaging services (Signal, Wire, Telegram, etc...) outpace email by a significant margin.
Today's messaging services (Signal, Wire, Telegram, etc...) outpace email by a significant margin.
I need a clarification
"In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash. The input to this hash includes a salt provided by the server on login but not stored in the client. In this way, compromise of the mailbox password does not automatically lead to compromise of the login password."
This means, if my password is "123hello" then the mailbox password is hash(derived("123hello"),secret_salt) where, hash is an hash algorithm (which one?), the secret_salt is a value stored in the server and never sent to the client, and the derived("123hello") is a password computed using the SRP protocol, which should be the session key explained here https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco..., correct? the part of the SRP and on how to genreate the password in SRP is a bit obscure to me, just trying to understand.
"In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash. The input to this hash includes a salt provided by the server on login but not stored in the client. In this way, compromise of the mailbox password does not automatically lead to compromise of the login password."
This means, if my password is "123hello" then the mailbox password is hash(derived("123hello"),secret_salt) where, hash is an hash algorithm (which one?), the secret_salt is a value stored in the server and never sent to the client, and the derived("123hello") is a password computed using the SRP protocol, which should be the session key explained here https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco..., correct? the part of the SRP and on how to genreate the password in SRP is a bit obscure to me, just trying to understand.
[deleted]
Nice to see wider adoption of ZKPP authentication.
>In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash.
I wonder what the password change procedure will be when you have several gigabytes of mail in your mailbox? Would you have to download every message, re-encrypt it in your browser and send back?
I wonder what the password change procedure will be when you have several gigabytes of mail in your mailbox? Would you have to download every message, re-encrypt it in your browser and send back?
Hopefully the mailbox encryption key is actually static, and they only store it encrypted with a key derived from your login password. If you use two different salts the knowledge of the login pw hash does not yield the mailbox key encryption key.
The mailbox encryption key is static. There is no need to re-encrypted all the mail when it is changed. Since the PGP Secret Key is only decrypted in the client browser or app, there is no need to transmit the decryption password to the server.
how practical is it to drop GMail for these guys? I'm tied fairly heavily to the Google ecosystem (Chome, Play, Finance, etc etc). They already have a mountain of data on me, but I really want to start taking encryption and privacy more seriously.
I didn't miss anything when I left Gmail, but I imagine it depends a lot on how you use email. I switched to Fastmail on my own domain and actually prefer the webmail interface over Gmail.
I mainly use IMAP via Mail.app on my laptop and phone, Pantheon Mail (formerly Geary) on my desktop. I use PGP wherever I can. I haven't received any spam at all yet, so I can't comment on how their spam filters compare to Gmail. I maintain a zero inbox – important stuff gets archived, and everything else is deleted. This means that I don't miss Gmail's search feature as hardly keep any emails. Obviously your mileage may vary here. They also support CalDAV and CardDAV – so all of my notes, contacts, calendar items etc. are synced across my devices.
I've moved from Google completely, and for the most part, I don't really miss them all that much.
- Search -> DuckDuckGo (I do miss Google here – DDG's search results pale in comparison)
- Gmail -> Fastmail
- Maps -> Citymapper and Apple Maps
- Chrome -> Safari on macOS, Firefox on everything else (my experience with FF is a bit 'meh' – it was incredibly laggy on my work laptop, but runs great on my desktop)
I mainly use IMAP via Mail.app on my laptop and phone, Pantheon Mail (formerly Geary) on my desktop. I use PGP wherever I can. I haven't received any spam at all yet, so I can't comment on how their spam filters compare to Gmail. I maintain a zero inbox – important stuff gets archived, and everything else is deleted. This means that I don't miss Gmail's search feature as hardly keep any emails. Obviously your mileage may vary here. They also support CalDAV and CardDAV – so all of my notes, contacts, calendar items etc. are synced across my devices.
I've moved from Google completely, and for the most part, I don't really miss them all that much.
- Search -> DuckDuckGo (I do miss Google here – DDG's search results pale in comparison)
- Gmail -> Fastmail
- Maps -> Citymapper and Apple Maps
- Chrome -> Safari on macOS, Firefox on everything else (my experience with FF is a bit 'meh' – it was incredibly laggy on my work laptop, but runs great on my desktop)
I have done the same, but with exception of being a paying customer for Play Movies and Play Music. I also buy extra GDrive storage, and use it for encrypted backups of my laptop (I have backup scripts that ZIP up my writing and work projects, GPG encrypt them, and I manually transfer the files to GDrive.
Google does derive real revenue from me, but not so much via their advertising business.
Edit: FastMail is a very good email service, BTW.
Google does derive real revenue from me, but not so much via their advertising business.
Edit: FastMail is a very good email service, BTW.
For others interested in Gmail -> Fastmail, Fastmail also has an inbuilt IMAP migration tool:
https://www.fastmail.com/help/receive/migratemail.html
https://www.fastmail.com/help/receive/migratemail.html
During my migration from GApps (prior to G Suite), I used this tool. I performed an initial migration before changing my MX records, then followed up a few days later with a second (partial) migration to pick up a few slackers.
I found the tool to be fast, comprehensive, and the partial migration was very effective.
I found the tool to be fast, comprehensive, and the partial migration was very effective.
I've recently made a similar switch to a few of my 'core' services. Aside from a strong privacy bent, one of my core requirements has been to lessen my dependency on US based companies and infrastructure.
One the search front, I've been finding https://www.startpage.com/ to be a really nice alternative to DDG.
One the search front, I've been finding https://www.startpage.com/ to be a really nice alternative to DDG.
I haven't received any spam at all yet, so I can't comment on how their spam filters compare to Gmail.
I receive more spam in my inbox than in Google Mail (I used Google Apps), but it's not extreme. Typically two or three spam mails per week.
Of course, you get a lot back. As you say, I better web interface and standards-conforming IMAP.
I receive more spam in my inbox than in Google Mail (I used Google Apps), but it's not extreme. Typically two or three spam mails per week.
Of course, you get a lot back. As you say, I better web interface and standards-conforming IMAP.
Pretty much the same here, DDG, Fastmail, Firefox, and Here Maps and Movit for mapping/traveling.
Honestly, DDG surpassed google search years ago. I've preferred Firefox for a long time, and Fastmail's UI and service is incredibly superior to GMail. I guess the cost might be the only downside.
Honestly, DDG surpassed google search years ago. I've preferred Firefox for a long time, and Fastmail's UI and service is incredibly superior to GMail. I guess the cost might be the only downside.
Right now, I also try to keep Google as far away from me as I can. Unfortunately, I don't own a domain myself. Have you tried out ProtonMail yourself? If so, do you think that it is a good alternative to a self-hosted server like Fastmail?
Fastmail is not self hosted it's like protonmail a mail provider. I also use fastmail, it's less expensive and more private than gmail
I have not used ProtonMail myself so I can't help you there I'm afraid.
While I use Fastmail with my own domain, it is not self-hosted. My MX records point to Fastmail's servers.
While I use Fastmail with my own domain, it is not self-hosted. My MX records point to Fastmail's servers.
Does Pantheon-Mail support PGP?
It does not. I really hope they add the feature soon – in the meantime I use gpg on the commandline.
I've been tempted to add the support in myself, however I do not have any experience with the elementary codebase or Vala, so a cryptographic system would be a very poor choice for a first project!
I've been tempted to add the support in myself, however I do not have any experience with the elementary codebase or Vala, so a cryptographic system would be a very poor choice for a first project!
One downside what totally prevents me from even giving ProtonMail a try is vendor lock-up. You'll be stuck with them with no option to migrate away while keeping historical data. No IMAP, no POP3, not even a proprietary backup format, nothing at all.
One could probably automate a browser to log in, iterate mailbox and dump contents, but that certainly won't be fun.
(Also, no way to use your own pre-existing key, only somehow generating a new one somewhere - not sure how exactly it's implemented and whenever I can trust it all...)
One could probably automate a browser to log in, iterate mailbox and dump contents, but that certainly won't be fun.
(Also, no way to use your own pre-existing key, only somehow generating a new one somewhere - not sure how exactly it's implemented and whenever I can trust it all...)
IMAP support is coming very soon. Engineers are working on the code, now. It's a more difficult task than people would imagine because the implementations of the IMAP standards by some clients (like Outlook) is a bit... "interesting".
How would this IMAP implementation work? Some kind of local proxy that does the decryption on-the-fly?
Yes, exactly. The client is able to install and run a local proxy/translator application on their machine (currently, it's called a "bridge"). Their IMAP client connects to it and it interacts with ProtonMail's APIs over HTTPS. Since the bridge runs locally, the private key is locally decrypted with the client's password. The password is never sent to the server. The decryption takes place locally in the bridge software running on the client's computer.
Since they use GPG internally I would imagine it simply presents GPG-encrypted mail to you and relies on the client having GPG support.
Currently, for me, lack of a calendar is holding me back. As well as some other features, but I could probably overcome those. Relevant uservoice: https://protonmail.uservoice.com/forums/284483-feedback/sugg...
Yeah, but it's planned. They also mentioned the calendar coming in a recent blog post.
In general, I should say I am pretty happy with protonmail. I've been using it for over a year now, however, in general I'm still pretty dependent on google for calendar, android, etc.
When it comes to spam, my feeling is that I do get more now. But as long as it is properly categorized -- which it is -- I don't really mind getting it.
In general, I should say I am pretty happy with protonmail. I've been using it for over a year now, however, in general I'm still pretty dependent on google for calendar, android, etc.
When it comes to spam, my feeling is that I do get more now. But as long as it is properly categorized -- which it is -- I don't really mind getting it.
Do you also get ads by protonmail itself or does it come from other websites? And is there any unsubscribe feature like in outlook?
No, these are not from protonmail. It's more like p-enlargements, pills etc.. As far as general marketing mails are concerned, no, I never saw an unsubscribe link.
yikes, yea a calendar is pretty important. I suppose org-agenda could substitute but the way Inbox organizes all my travel is worth the fact that Google knows i'm flying to London.
>> They already have a mountain of data on me, but I really want to start taking encryption and privacy more seriously.
> I suppose org-agenda could substitute but the way Inbox organizes all my travel is worth the fact that Google knows i'm flying to London.
Well.. at some point you have to choose something over the other.
> I suppose org-agenda could substitute but the way Inbox organizes all my travel is worth the fact that Google knows i'm flying to London.
Well.. at some point you have to choose something over the other.
What you'll want is to forward your Gmail to ProtonMail as soon as possible, because otherwise you'll always visit Gmail first. So forward Gmail and then just keep a pinned ProtonMail tab open, and get rid of whatever Gmail notification extensions you may have. Also disconnect the Gmail mobile app and set-up ProtonMail on mobile.
https://protonmail.com/support/knowledge-base/transitioning-...
What may give you a push is that Google seems to be trying to make Gmail a more proprietary and less of an interoperable standardized email service. Eventually it may not be as easy to get out of that "lock-in" as it is now (even though it seems hard, but it's mostly a matter of habit and will to change to a new service).
https://protonmail.com/support/knowledge-base/transitioning-...
What may give you a push is that Google seems to be trying to make Gmail a more proprietary and less of an interoperable standardized email service. Eventually it may not be as easy to get out of that "lock-in" as it is now (even though it seems hard, but it's mostly a matter of habit and will to change to a new service).
So I've actually been transitioning my personal communications over to Protonmail (on a custom domain to future proof the address), and keeping Gmail for transactional emails (because of utility in Inbox grouping, Google Now, etc).
I've realized that I don't really care about Google having access to my transactional mail (things knowable from third parties anyways), but do want personal communications properly encrypted. Basically, I've only moved over my "priority inbox," and keep using Gmail for junk.
Very satisfied with Protonmail though. Especially knowing they are working on fixing their lock-in issues.
I've realized that I don't really care about Google having access to my transactional mail (things knowable from third parties anyways), but do want personal communications properly encrypted. Basically, I've only moved over my "priority inbox," and keep using Gmail for junk.
Very satisfied with Protonmail though. Especially knowing they are working on fixing their lock-in issues.
It's worth noting that "things knowable from third parties" and "an aggregation of all your things knowable from third parties" are very different risk profiles, if that's the deciding factor for anyone.
No caldav and carddav implementation are available yet. So if you heavily depend on these it might not yet be ready for you yet. For occasional mailing I find protonmail pretty good - browser and apps.
You could use Fastmail.
similar to https://www.caplinked.com 's http://www.attachd.com
This all seems to be a web-based application (https://github.com/ProtonMail/WebClient). How are the security issues regarding knowing that you're always running that code and that the server isn't compromised and sending altered code? The arguments against server-supplied, js-in-the-browser crypto have been done to death.
Why is this any different, and why am I wrong to dismiss it out-of-hand as (in)secure as simply sending unencrypted data to the server? Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server).
> we choose our own primes rather than those used by TLS
Does TLS specify any primes? You can use your own DH primes, SRP primes, and your key is your own prime. Those RFCs recommend primes, but allow the server to use different ones. TLS, SRP, or DH doesn't "use" a single prime, any prime satisfying the requirements in the RFC is acceptable. know it's nitpicking but something about how it was said rubbed me the wrong way.
I would love to know how they communicate between their TLS-SRP layer and their authentication layer. Most implementations are file-based. Did they write a plugin for gnutls or openssl? Did they write their own TLS layer?
I would love for TLS-SRP to be more wide-spread, but this is always the biggest hurdle to adoption in my case.
Why is this any different, and why am I wrong to dismiss it out-of-hand as (in)secure as simply sending unencrypted data to the server? Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server).
> we choose our own primes rather than those used by TLS
Does TLS specify any primes? You can use your own DH primes, SRP primes, and your key is your own prime. Those RFCs recommend primes, but allow the server to use different ones. TLS, SRP, or DH doesn't "use" a single prime, any prime satisfying the requirements in the RFC is acceptable. know it's nitpicking but something about how it was said rubbed me the wrong way.
I would love to know how they communicate between their TLS-SRP layer and their authentication layer. Most implementations are file-based. Did they write a plugin for gnutls or openssl? Did they write their own TLS layer?
I would love for TLS-SRP to be more wide-spread, but this is always the biggest hurdle to adoption in my case.
>Why is this any different
Nobody says it's different
>Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server).
OK, let's suppose you're using a native app. One day vendor issues an update with some critical vulnerability patched. Unfortunately, another vulnerability (or even backdoor) sneaks into this update for whatever reasons. How is this any different?
Nobody says it's different
>Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server).
OK, let's suppose you're using a native app. One day vendor issues an update with some critical vulnerability patched. Unfortunately, another vulnerability (or even backdoor) sneaks into this update for whatever reasons. How is this any different?
An update to the native app must be the same for everyone, and being open source, the chances that someone will find out about it are much greater.
In a web app, they can send a backdoored copy of the code just to you and just a single time, which is much harder to detect.
In a web app, they can send a backdoored copy of the code just to you and just a single time, which is much harder to detect.
> Nobody says it's different
They why do all the extra work for no gain in security?
I think the sibling comment address your next comment well.
They why do all the extra work for no gain in security?
I think the sibling comment address your next comment well.
There's a difference between an active attacker and a passive MITM attacker. Doing this for the web app in addition to the native apps helps prevent a passive MITM attack from stealing login credentials.
A mitm is an active attacker. If TLS fails, then the mitm could modify the code sent to the end user.
That's a limited definition of MITM. That would be an active attack, and yes, this does nothing for that for the web app--the native apps are a different story. However, there are plenty of corporate PCs and other machines with root certs installed in a way that a third party could, and often does, passively record traffic without modification for analysis later. SRP prevents those dumps from containing information that can be used to compromise an account.
That is exactly what I'm describing though. The corporation could edit the page to do what they want. To claim otherwise is foolish and really makes me question proton's understanding of security.
>How are the security issues regarding knowing that you're always running that code and that the server isn't compromised and sending altered code?
A unique solution might be to use service workers to handle content "updates". The assets could be cached locally, and a single network request could be fired to check for updates. If one exists, the user is prompted to update. This would at least alert you to review the code being sent to your browser if you're so inclined.
Ultimately though it comes down to yet another tradeoff of security vs convenience. Such a feature might be better off as an opt-in extra security feature.
A unique solution might be to use service workers to handle content "updates". The assets could be cached locally, and a single network request could be fired to check for updates. If one exists, the user is prompted to update. This would at least alert you to review the code being sent to your browser if you're so inclined.
Ultimately though it comes down to yet another tradeoff of security vs convenience. Such a feature might be better off as an opt-in extra security feature.
Sorry for any confusion. We don't use TLS-SRP, we use certificate TLS, and SRP on top of it. The short discussion on TLS-SRP was trying to address any potential questions about different choices we made with respect to TLS-SRP.
Also, yes, the application is web-based, but we also have native mobile clients which use the same API, and are working on two more native options for desktop.
It should be reminded that emails exchanged between Protonmail and any recipient who use ordinary email server are not secure. In order to achieve security you have to mail with other Protonmail user or use PGP.
They have an option to send a secure email to "normal" email addresses which works by sending them an https link to click. You must have a pre-arranged password with the other person for this to work, but it is possible.
I wondered why they didn't do this. As a customer, this is a welcome change.
One thing that is of general concern to me: I tend to use a lot of encrypted traffic because much of my work is done on SSH shells to servers, and some of my customers request encrypting work files and use VPNs. With also using ProtonMail, I would expect to be on a government list of some sort. Given the general anti-privacy and anti-encryption rhetoric from public government officials this is a concern.
What our government should do is a moon-shot level of effort to promote strong encryption and very robust digital infrastructure. While this might unfortunately make law enforcement's job a little more difficult, the advantages in fighting computer crime and generally saving businesses, citizens and the government money would be worth it. I think it would also increase our level of national security, with all of our systems less hackable.