"In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash."<p>I wondered why they didn't do this. As a customer, this is a welcome change.<p>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.<p>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.
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 name@mydomain.com and I want to move from Google Apps + GPGtools to Lavaboom/Protonmail/etc).<p><a href="https://github.com/lavab" rel="nofollow">https://github.com/lavab</a><p>our (brilliant) designer <a href="http://www.felixvonlooz.com/" rel="nofollow">http://www.felixvonlooz.com/</a>
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...
I need a clarification<p>"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."<p>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 <a href="https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol" rel="nofollow">https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...</a>, 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.<p>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?
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.
similar to <a href="https://www.caplinked.com" rel="nofollow">https://www.caplinked.com</a> 's <a href="http://www.attachd.com" rel="nofollow">http://www.attachd.com</a>
This all seems to be a web-based application (<a href="https://github.com/ProtonMail/WebClient" rel="nofollow">https://github.com/ProtonMail/WebClient</a>). 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.<p>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).<p>> we choose our own primes rather than those used by TLS<p>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.<p>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?<p>I would love for TLS-SRP to be more wide-spread, but this is always the biggest hurdle to adoption in my case.
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.