Anyone that values their privacy should never trust a service like this. The idea of in-browser encryption and decryption is nothing new, and it always suffers from the fact that the server can replace the client side software at any time without warning. If you must use a browser, find a plugin that you trust that works with any webmail service. Better yet, use an actual mail client and encrypt/decrypt in that.
Show HN: End-to-end encrypted email, based in Switzerland
41–50 of 71 posts
Re: Show HN: End-to-end encrypted email, based in Switzerland
#42Re: Show HN: End-to-end encrypted email, based in Switzerland
#43This appears to be a PHP wrapper around OpenPGP.js. If the encryption comes from Javascript loaded by browsers from the servers every time they visit the site, the encryption isn't "end to end". It's controlled by the server and can be broken by the server. Also: the RSA Security logo isn't the logo of the RSA algorithm; it's the logo of the company that sells RSA tokens.
I knew this is the first thing I would read. We are becoming pretty predictable. I tire of hearing this repetitively, every time somebody attempts to take this path, but I recognize you are doing it for anybody that is new and didn't hear the other warnings. Isn't the perfect the enemy of the good? Can we recognize that this is a good first step, and definitely constitutes a huge improvement over gmail/yahoo type web…
There is no need for niceties when you're trying to promote something as secure when it isn't.
Re: Show HN: End-to-end encrypted email, based in Switzerland
#44Earlier quoted context omitted.
Why can't browsers just build crypto primitives in that can be called from js? I don't understand what people's obsession with browser crypto is...but I don't know enough about browser's to think of a reason this solution is bad. Any guidance? edit: I understand that this won't solve all the problems...but at least the problem that you are constantly being served this chunk of potentially unsafe code. edit2: I've bee…
It is a long story and has been discussed one million times on here at least. Google the answer or just trust that crypto in JS cannot be not because the implementation is hard but because it is not possible in principle.
Re: Show HN: End-to-end encrypted email, based in Switzerland
#45Earlier quoted context omitted.
You can't just review "openpgp.min.js". You have to review every single Javascript input and every single DOM node , and any of them can alter the behavior of any other element of the Javascript runtime in subtle ways to subvert cryptography. And you have to do this every time you load any page on the site, and any time any of those pages asynchronously load any content. So, no, contrary to popular belief, this doesn…
Why can't browsers just build crypto primitives in that can be called from js? I don't understand what people's obsession with browser crypto is...but I don't know enough about browser's to think of a reason this solution is bad. Any guidance? edit: I understand that this won't solve all the problems...but at least the problem that you are constantly being served this chunk of potentially unsafe code. edit2: I've bee…
The danger is that you are back to trusting the server. If they are compromised, you could get served special crypto code that uploads your private pass phrase the next time you log in.
The crypto code needs to come from a trusted third party, and the protocol with the server must be dead simple and strictly arms-length, with no logic of any sort downloaded from the server. More like FTP than HTTP/HTML/JS.
Re: Show HN: End-to-end encrypted email, based in Switzerland
#46This is a dangerous and insane misunderstanding of the trust relationships work in the public CA system.
Any CA can impersonate any site. Your choice of CA has no bearing on your exposure to this risk.
(If this were an app or browser extension, you could plausibly pin the right certificate path to only trust SwissSign. But if you can do that, you can just pin your certificate and don't need a CA at all.)
Re: Show HN: End-to-end encrypted email, based in Switzerland
#47Earlier quoted context omitted.
Well, selling out American millionaires is one thing, I have a feeling the Swiss would be less willing to sell out private communications to the NSA.
Because...
https://en.wikipedia.org/wiki/Crypto_AG#Back-doored_machines
Re: Show HN: End-to-end encrypted email, based in Switzerland
#48Earlier quoted context omitted.
I don't know about the "perfect" and the "good", but the "trivially breakable" is definitely the enemy of "keeping secrets from governments".
You choose to ignore my point. Obviously you know about "perfect" and "better than gmail", right?
Re: Show HN: End-to-end encrypted email, based in Switzerland
#49This appears to be a PHP wrapper around OpenPGP.js. If the encryption comes from Javascript loaded by browsers from the servers every time they visit the site, the encryption isn't "end to end". It's controlled by the server and can be broken by the server. Also: the RSA Security logo isn't the logo of the RSA algorithm; it's the logo of the company that sells RSA tokens.
I knew this is the first thing I would read. We are becoming pretty predictable. I tire of hearing this repetitively, every time somebody attempts to take this path, but I recognize you are doing it for anybody that is new and didn't hear the other warnings. Isn't the perfect the enemy of the good? Can we recognize that this is a good first step, and definitely constitutes a huge improvement over gmail/yahoo type web…
Re: Show HN: End-to-end encrypted email, based in Switzerland
#50Earlier quoted context omitted.
Why can't browsers just build crypto primitives in that can be called from js? I don't understand what people's obsession with browser crypto is...but I don't know enough about browser's to think of a reason this solution is bad. Any guidance? edit: I understand that this won't solve all the problems...but at least the problem that you are constantly being served this chunk of potentially unsafe code. edit2: I've bee…
The problem with browser crypto is that code is downloaded from the server ... nothing to install, so convenient. Right? The danger is that you are back to trusting the server. If they are compromised, you could get served special crypto code that uploads your private pass phrase the next time you log in. The crypto code needs to come from a trusted third party, and the protocol with the server must be dead simple an…
You're echoing the problem that my question is asking if it solves...
Edit: Also, you definitely need more than the code to come from a "trusted third party", otherwise we would see SaaS startups on HN providing "crypto as a service" (god help us).