Live data from Hacker News

Show HN: End-to-end encrypted email, based in Switzerland

protonmail.ch

61–70 of 71 posts

Re: Show HN: End-to-end encrypted email, based in Switzerland

#61
post #56

Earlier quoted context omitted.

You conflated two things. Yes, having full source code is a sufficient condition for security. But you also implied that the hypothetical browser crypto primitives would allow one to do anything they want with the decrypted data, which might be too loose of an assumption. For example, you could make the browser crypto primitives work so that you can only display unencrypted data (or a private key) but not be allowed…

Sure, if you want to break JS the language. JS doesn't have a concept of "here have a variable with data inside of it but you cannot touch it". Ask yourself: "what does 'display' unencrypted data mean?"You are describing a different system entirely from what an HTML renderer + JavasScript engine can do.

> JS doesn't have a concept of "here have a variable with data inside of it but you cannot touch it".

Actually, it does: closures (and WeakMap in ES6 has similar properties). They're pretty foolproof for information hiding, if used properly. (But this is irrelevant to tptacek's point about the security of crypto in JS, of course.)

Re: Show HN: End-to-end encrypted email, based in Switzerland

#63
post #59
post #54

Earlier quoted context omitted.

tptacek, can you suggest a design for end-to-end email encryption delivered through a browser? As theboss mentioned [1], is: (a) browser crypto theoretically impossible, is it (b) that something's practically from browsers today (like build-in crypto code) for a practical solution, or is it (c) that existing attempts have not attempted to do something that is theoretically possible? If I understood you correctly, you…

Verification isn't possible in modern browsers. This is an inherently hard problem, one that has caused some people who've launched carefully-designed encrypted mail systems to abandon the effort.

Am I understanding you correctly that verification IS possible in browsers, just not the existing modern ones (e.g. because of limitations in the existing modern ones) and that browser crypto is possible?

(I recognize it might inherently be a hard problem, but hard does not equal impossible. I also recognize there are benefits to a simpler solution that can outweigh the benefits of a harder solution.)

Re: Show HN: End-to-end encrypted email, based in Switzerland

#64
With respect to their servers' location in Switzerland, if you don't live in Europe, that will not benefit you. Even the best of laws require you to actively defend yourself. I for one cannot travel to Switzerland and represent myself in a Swiss court, at least not at a tolerable cost.

Re: Show HN: End-to-end encrypted email, based in Switzerland

#65
post #7

This 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.

When I see the RSA logo, I must reconsider using this service.

Re: Show HN: End-to-end encrypted email, based in Switzerland

#67
post #19

Is "Based in Switzerland" relevant in this case? I know their government is historically neutral in major wars. Are they also a good place to base security-minded companies?

Switzerland is currently in a state of flux. They are adopting to "international" laws at astonishing speeds. A safe heaven for data privacy? Think twice:

http://arstechnica.com/tech-policy/2013/12/switzerland-wont-...

That's the current status quo. And members of the Bundesrat (the executive gov body) have proposed more plans to ease the use of wiretaps.

Re: Show HN: End-to-end encrypted email, based in Switzerland

#68
post #7

This 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.

But but ... MIT, Caltech, Switzerland, CERN ... amirite?

No honestly, thank you for your comment and the ensuing discussion - most people get swayed by big names and such and reading sincere criticism of this sort of stuff is important and educating.

Re: Show HN: End-to-end encrypted email, based in Switzerland

#69

Earlier quoted context omitted.

Sure, if you want to break JS the language. JS doesn't have a concept of "here have a variable with data inside of it but you cannot touch it". Ask yourself: "what does 'display' unencrypted data mean?"You are describing a different system entirely from what an HTML renderer + JavasScript engine can do.

> JS doesn't have a concept of "here have a variable with data inside of it but you cannot touch it". Actually, it does: closures (and WeakMap in ES6 has similar properties). They're pretty foolproof for information hiding, if used properly. (But this is irrelevant to tptacek's point about the security of crypto in JS, of course.)

I don't think this is what the grandparent is envisioning. Also closures are great until you are able to replace the code that produces them, or read straight from the DOM at the place where you mail client is displaying the decrypted data.

Re: Show HN: End-to-end encrypted email, based in Switzerland

#70
post #38

Earlier 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…

Since you insist on a longer explanation, here goes: You can have crypto primitives in the browser: AES, RSA, ECDSA, etc. So given a private key and cyphertext you can decrypt it and given a public key and a piece of cyphertext you can encrypt it. The actual crypto code is just a callout to libssl. In this regard, you can do this right now: simply wrap libssl from within Chrome's JS engine and you are done. Now what?…

Except that HTTPS does not let you encrypt/decrypt data using your own key for example. I am thinking of things like S/MIME.
Post reply on HN