ProtonMail now the maintainer of OpenPGPjs email encryption library | Hacker News Reader

ProtonMail now the maintainer of OpenPGPjs email encryption library

protonmail.com

107 pointsedvbld28 comments

In case anyone looks for the same thing, I saw "ProtonMail is community software, funded by the community, and open source." and jumped to GitHub to search. As stated in https://github.com/ProtonMail/WebClient/issues/5, the only open source part is the JavaScript based client, so you can't self-host ProtonMail.

So my first reaction there was "there goes another non-five eyes (or nine or fourteen eyes) hosted mail service who've just painted a (or another) great big target on themselves to attract even more NSA scrutiny".

(Second reaction was "Crypto in the browser in Javascript _again?_ Didn't was already point out this is 'doing it wrong'?")

So you'd prefer not to have any crypto at all? Because 99% of people are going to use their browsers anyways.

Btw for example https://blockchain.info/wallet/#/ (in-browser bitcoin wallet) I think has never been hacked - you might say it's a huge outlier but it is possible to do well.

I'm building a chat platform with js and https crypto. It's better than nothing in my opinion.

A false sense of security is worse than nothing at all.

Is it worse than just Https? I'm not advertising the feature loudly, I just want to keep nosy sysadmins on corporate networks with https inspection out of private conversations. It obviously can be broken by NSA types if they want to actively alter traffic, but passive monitoring should be harder. Also this forces the attackers hand, an attack against this system can be detected if you want to spend the time comparing hashes.

> Also this forces the attackers hand, an attack against this system can be detected if you want to spend the time comparing hashes.

You could have an extension which checks the hash of the js/html payload against a publicly known and signed hash prior to running and rejects it otherwise. It's still browser crypto but potentially you do better than 'everything is broken if the ssl session is hijacked'.

True - and it's complex - but you need to keep the capability of your adversary in mind.

This will thwart your nosy flatmate/little-brother.

This is reasonably likely to keep curious or nosy corporate IT or HR staff at bay if you use it at work. It's not going to keep a properly authorised and resourced corporate IT investigation/surveillance out - at least not for any hardware that's got corporate ssl roots installed (or device management that allows installation of those).

It'll likely keep local cops out. It's less likely to keep feds out if they're determined. It 100% will not help against people who've got browser trusted ssl signing roots and the ability to run QUANTUM on exploited backbone routers to deliver their own versions of the javascript appropriately ssl encrypted to you before the actual site has a chance to respond.

Another vector is I won't really be able to respond to requests from law enforcement because as soon as the chat is over (or on request of the creator of the chat) I wipe the key from memory. Leaving only encrypted blobs in the database that are then purged themselves at a later time. The key is never written to the disk to prevent forensic analysis there as well. As a bonus, I can handle a decent number of users with a small amount of hardware as most of the hard work is done client side.

Lastly, I'm planning on implementing all of the best protections we have against man in the middle attacks currently like subresource integrity and HSTS. If the browser committees give me something better (maybe some sort of resource signing that can be verified on a secondary secure channel?) I'll implement it. So it may protect against more in the future.

That kind of policy didn't work out so well for Ladar Levison at Lavabit when they wanted to subvert the entire userbase's security just to get access to Snowden's email account...

If you piss off important enough people - law enforcement won't just go away when you say "the system isn't capable of doing that", they'll say "so re-write the system so it is, and if you tell anybody we'll put you in jail forever".

The FBI have seized and continued to run a child porn website before to gather evidence - do you _really_ think they'd hesitate before taking over your encrypted chat servers if they thought it'd get them a career-advancing prosecution? Do you think you'd fight as hard as Ladar did when the guys with guns come knocking at your door? (I have no doubt I'd cave pretty quickly - I've got a lot of respect for Ladar's resistance to selling out his users...)

I thought of that, the project will be FOSS and I'm going to encourage people to run their own servers. The primary server will mostly be a reference implementation and for casual chatting.

No no - it's most likely a "good thing"(tm)

It's not like I trust my browser and https any less than I trust my phone's baseband processor and it's NSL-able telco-end backdoorability...

The issue is like this.

I load https://webmail.example.com.

I see my email.

My ISP doesn't see my email.

The NSA (or anyone else who can MITM https, such as my workplace, college, etc.) can effectively turn it into http, and see the content.

We need to fix that.

So I write an encryption library in JS, loaded from https://webmail.example.com . It loads the email through an AJAX call from https://webmail.example.com, decrypts it, and displays it.

The only issue is that whoever can MITMed the connection can also modify the JS file to send the key to a C&C server.

So:

"Dumb" ISP can't read #1 mail

"MITM" ISP can read #2 mail

So what's the gain?

The only concern is that it's an active attack vs a passive attack, so no plausible deniability.

But in most MITM scenarios, you don't need plausible deniability.

1. Your workplace computer and the connection is owned by them, so they can do what they want with it.

2. Dictatorships give themselves whatever powers they want

3. The NSA has enough side-channel attacks to exploit.

So in which situation will a "JS" encryption help?

> The NSA (or anyone else who can MITM https, such as my workplace, college, etc.) can effectively turn it into http, and see the content.

To be clear, unless NSA has some massive capabilities we haven't dreamed off, properly implemented HTTPS cannot be MITM'ed (via SSL stripping, or other means) by anyone who lacks access to your local machine. Specifically, by properly-implemented SSL, I mean:

1. Serving https only, no http

2. HSTS

3. Certificate pinning

The situation you mention regarding workplace computers is a little different from the NSA, since they have the explicit authority and ability to install root certificates on your local work computer. Without those root certs (like if you use a personal computer at work), they lack the ability to MITM your connection, assuming the above.

If I'm the NSA, I'd already have stolen Protonmail's HSTS pinned cert's private key (possibly by burning a zero day getting into one of their web servers, possibly by "asking nicely" to some tech employee there for whom I had appropriate leverage).

But yeah - short of nation-state or very high level LEO (who're just piggybacking on their local NSA equivalent), HSTS with pinned certs is as close to "secure" as we have right now.

This is why we have HSMs.

It can in fact be "impossible" to steal ones crypto keys.

Yeah, but "stealing" them isn;t the NSA's only avenue to acquire them. With Lavabit they just said "give us the keys so we can snoop all we want" - I suspect very few of us would be able to resist like Levinson did (as in, shut your company and livelihood down, and hope they don't throw you in jail for doing so). (Fortunately, most of us won't have users with as much heat coming down on them as Snowden, but if you're building _anything_ privacy related you owe it to yourself to consider how far you'd go to protect your users if one of them turned out to be another Snowden...)

"stealing" is the only path the NSA can take in the case of ProtonMail, due to their servers being hosted in Switzerland and not within the borders of a nation that has a strong relationship with the US intelligence community.

I'd bet good money that the NSA can outsource this to their friends/counterparts/lackeys in any of five eyes, nine eyes, and fourteen eyes countries - and through less official channels involving local or flown-in thugs, pretty much everywhere else. They probably can't easily get Huawei's or Baidu's private keys, but I bet there's tens or hundreds of thousands of Protonmail sized companies in China/Russia/everywhere else that they _can_ strongarm the owners or sysadmin staff into handing keys over.

Or maybe I'm just in a way too "the whole world is fucked" mood today...

Only if you are sure the HSM isn't rigged from the start.

Another thing in the security tool chest is SubResource Integrity. If your JS is hosted on a CD you can put a hash of the expected JavaScript within the HTML script declaration. When the browser downloads it, it'll verify the hash before executing it.

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Reminder for the obvious: Javascript is now longer just for web browsers and GPG is not just for email. GPG is also used in B2B scenarios where files are being passed between between servers.

Also Javascript based client applications installed locally are becoming more common (think about Atom etc). Maybe we will soon also see Javascript based desktop IMAP client.

> Javascript based desktop IMAP client

Nylas N1 is an example of this (and excellent, might I add)!

https://nylas.com/

Thanks for the kind words! (I work at Nylas.)

Here's a blog post with more details about Nylas N1 and PGP: https://nylas.com/blog/pgp

I'd rather desktop clients written in JavaScript talked to gpg-agent. OpenPGP.js wont let me use my smart card or my yubikey and I don't want to have to maintain multiple keyrings on the same system because some apps want to use GnuPG and others OpenPGP.js

I hope the will accept our pull request for adding secp256k1 to OpenPGP.js enabling interaction with OpenPGP and use of cryptocurrency keys for messaging: https://github.com/Jaxx-io/openpgpjs-secp256k1

It seems that WebCrypto is already implemented in browsers. Does this library make use of it, or is it pure JavaScript? If so, why is that? Most crypto algos are susceptible to side channel attacks, and trying to get that right in JavaScript across browsers doesn't look generally possible.

Good stuff, paying customer and planning to stay one :) I do wonder though if you are thinking about providing PM as a browser extension based app as well? Would curb some of the issues people always bring up re crypto in browser.

Reply on news.ycombinator.com