I think you are confusing Java with JavaScript in this post.
I have limited working experience with secure code (read: I followed an outdated guide on implementing a PHP login system using MD5 once) - but the reason JavaScript is unsuitable for this task is because web browsers readily expose all the source code and allow its manipulation.
Yes, nothing is 100% secure, but a crypto system built in JavaScript and executed in a browser is pretty much 0% secure.
Give it at least some credit. I’d say it’s about 20% secure 
I wonder if a better approach to this problem would be to scrap the difficult goal of end to end encryption?
Instead, focus on on-server message encryption, using some kind of two-factor system like one-time pads - this would not protect against man in the middle attacks but would protect against the more general case of people other than the intended recipients attempting to access a message thread (i.e. staff, database thieves, people who hack into accounts).
This is around the same level of security that banks (at least, British banks) implement, so in general users should be comfortable with that kind of “ux penalty.” IMO any security improvements should be usable by a user of any skill level… PGP is not, but some kind of one time password system might be
In general, what banks use is just SSL and all around good security hygiene, with some marketing fluff so you feel safe banking online with them. I’m not aware of much else they do beyond that.
Here in the UK all the major banks have mandatory 2FA, either one-time pad devices or card readers which take a PIN. So there’s an extra element of security there. I think this makes it ok to implement 2FA everywhere - it’s no longer too complicated a technology if even banks believe their customers can use it.
I don’t know what they do in other countries, though from what I gather, the US is barely even using Chip-and-PIN for cards…
Edit: @fysics I just noticed that nothing in that post mentions 2FA. I had a sentence about one-time passwords, I don’t know where that went… I’ll put it back 
@haiku lol, it must just be US banks that are crappy about security. Figures.
So long as your messages pass through the server running discourse, encrypting them or not encrypting them is moot. It isn’t even a matter of trusting the administration of the website either. Services like Hushmail have been compelled by court orders in the past to capture users keys / passphrases using either javascript or “a compromised java applet”. (US v. Tyler Stumbo) Other encrypted messaging services have simply disappeared, presumably because they refused to comply with orders of this kind and shut their service down on principle. In this environment, any encryption beyond https becomes superficial.
I would definitely support an encrypted messaging service if it’s implemented in a p2p fashion. Doing it p2p also necessitates that both users are online when the messages are sent, so it’s probably best implemented as an instant messenger type service.
An implementation of the tox protocol in EC6 might be the most elegant solution for that type of encrypted messaging.
I think I understand this point, just want to clarify the situation for a web app like Discourse.
So… this feature (secure asynchronous communication) is pretty much unviable without an mechanism external to Discourse itself (a non-browser encryption client).
If that’s the case… then I guess there’s no way around it! To provide this feature you need to build something external… which means there’s not really any point of building it as part of Discourse at all . Right? 
P2P encrypted chat sounds like a cool feature, though. I hear chat topics are somewhere on the roadmap, so maybe this could be integrated into that.
All of that being said, it seems like a lot of programming and computational overkill just to shield your “private” messages from a third party (namely the administration of the web service you’re using). If two users inside a community are concerned about the website intercepting their communications, they should (and would) communicate independently by other mechanisms outside of that website (such as tox 
).
As far as just an instant-messaging-like feature, that would rock! I cringe at saying it, but I’d like to see it follow in facebook’s steps, so that instant messages are simply another way of displaying your inbox. That is to say, there isn’t a duplication of features between instant messages and other private messages. They’re simply displayed differently.
Yep, that is how I’d like it to work as well! Facebook-style private chat would work very nicely in Discourse, of course in addition to public IRC-style chat topics.
There was some discussion about that here:
https://meta.discourse.org/t/using-discourse-as-a-chat-application/3436
, but…
I think it might have to be a community-led effort!
That was my fear, but it’s probably for the best.
Count me in!
Before you can even tackle the problem of running JavaScript securely you need to consider the following:
The User must trust the server as long as the public keys are delivered through it.
Trust must be established between the clients and the server and the system. The server controls all the communication between the clients, deliver and managethe public key for each user.
If user want to send a message to user B, it will first ask the server for User B’s public key.
The server is capable to mask the public key of user B with its own crafted public keys and circumvent the entire communication between the users.
Therefor If you don’t trust the server or its operators the entire idea is flowed.
hypothetically you trust the system enough that even a malicious user is not able inject or alter the code.
If someone is able to inject javascript, then it is like giving an attacker remote access to your browser tab.
To make it less susceptible to client side attacks (javascript injection), The encryption should operate on its own domain sub service.
Client A --> Request A secure communication channel with client B
Server <-- Returns a token on the secure domain.
Client A open a new window to http://secureChannel.discourse.com/Composer/?token=RandomToken
client A can see that the composer is on a trusted server / domain (Check 1)
The window on the secureChannel domain will now have a composer and the list of recipients Name and avatar, Allowing the User to visually confirming the token is legit and that there are no attempt to leak its message to a different user or a different site (Check 2)
If the user is able to trust the secureChannel.discourse.com You can also safely run Javascript based PGP.
compromising the main site www.discourse.com with Javascript injection should not affect the secure channel on secureChannel.discourse.com.
Ideally to provide an even higher level of user authenticity, an independent 3rd party can be used to authenticate users public keys.
With a secondary check to a trusted 3rd party a user can verify if the public key does not match and avoid sending the potentially insecure message. like an SSL certificate and certificate authority .
Using a 3rd party check may require trusted code(external software or potentially a browser extension) to authenticate both the main site and the check server are matching. The check can not run on the main site if there is a risk that main site will get compromised.
@haiku, you seem to occassionally conflate authentication with privacy. Two Factor Authentication does authentication, it helps to securely establish a user’s identity. It does not offer better privacy.
@fysics, a Java applet could still work if it’s open-source, peer-reviewed and includes a build harness that helps users build it themselves with minimal dependencies, ideally just the Oracle JDK. If the encryption isn’t your business model, it can be a community effort, and communities generally don’t care about national security letters (or your regional equivalent).
All that said, there are two features that could be implemented for Discourse:
First, encrypting emails generated by Discourse to protect against nosey MTAs or client-side mail scanning such as Gmail. This could be done using PGP and keys uploaded by users, but X.509 certs and S/MIME would work just as well.
Second, Discourse could act as a PGP keyserver, assuming that key trust is established by the users themselves via a web of trust. Combine this with support for sending PMs to other users via email and secure communication becomes possible via strictly client-side authenticated encryption (e.g. Thunderbird+Enigmail), using Discourse as a mere message relay.
But a dumb message relay is just not what Discourse wants to be. And regarding the chat thing, I’m not sure if Discourse should compete with something like XMPP+OTR for user-to-user chat. Multiuser chat is a totally different beast, anyways, and end-to-end encryption in that scenario makes hardly any sense. 
This is quite a good discussion about browser-based cryptography:
https://www.tbray.org/ongoing/When/201x/2014/06/08/Trusting-Browser-Code
…with a link to one strong opinion that it will never be safe:
That is a fantastic article, thank you for that link.
I really hope we can finally put this discussion to bed now. 
I really hope we can finally put this discussion to bed now.
I’ve been watching this, and related threads, for a couple years now. Not being a developer, I keep hoping someone more optimistic will take another look at this and get excited about it.
In the 30+ months since the last post, ProtonMail has made significant strides in PGP/GPG email. This includes their increased role in overseeing the OpenPGP.js library.
As well, Facebook has recognized value in their implementation of PGP encryption of notification messages.
Much of the negativity in this thread seems to be related to threat models relating to #Vault7 level attacks (which obviously doesn’t make sense on forums, which are relatively public to begin with) or rogue admins. That’s fine. Points well taken.
However, privacy relating to nefarious and successful attacks attacks against common email account providers – now numbering in the billions – continue to pile up. Scrolling through my admin screens it’s shocking how many yahoo, gmail and even hotmail addresses are in regular use. Having at-rest emails encrypted by PGP (or otherwise) is just good policy.
Furthermore, it’s my belief that the most prescient threat models are those which take Big Data used by corporations for the manipulation of human behavior (e.g., advertising) into consideration. Again, the big email providers are responsible for much of this.
The idea that the only concerns users and admins should have contain 3 letters and are taxpayer funded is somewhat myopic.
I prefer this sentiment: Let’s Encrypt Everything
it’s clear that everything on the web should be encrypted by default.
Why?
- You have an unalienable right to privacy, both in the real world and online. And without HTTPS you have zero online privacy – from anyone else on your WiFi, from your network provider, from website operators, from large companies, from the government. – @codinghorror
I understand that PGP is imperfect, but c’mon… Facebook and WordPress can’t have all the fun.
Maybe someday I’ll open my inbox and see all of my Discourse notifications with that purdy green lock…
This article from 2011 is still fairly relevant today
There are 2 possible solutions I see out of this mess.
Ubiquitous implementation of web cryptography APIs Web Cryptography API and JavaScript PGP available everyone’s in browsers
Extend Discourse app to support PGP messaging
I very much agree with the age old concerns that you simply can not trust the origin that serves you your js bundle not to mess up something and serve you a security hole. If this is provided by the app or by cryptography apis in the browser it is far more auditable and secure.
An illusion of perfect privacy is far more dangerous than no privacy at all.
An illusion of perfect privacy is far more dangerous than no privacy at all.
Agreed. I’m also reminded of the cliche, “don’t let the perfect be the enemy of the good.” Errrr… don’t let perfect privacy be the enemy of Pretty Good Privacy (I feel like you set me up for that one!).
In the WP PGP Encrypted Emails plugin, and the Facebook OpenPGP implementation, there are multiple places to apprise the user of the imperfectness of the privacy. Both require adding a public key to one’s profile. In the case of FB, once the key is entered, a PGP encrypted email confirmation message is sent to verify the key is accurate (on FB’s end and the user’s end) before messages are encrypted. A prompt to the user about limitations could be provided in the UI and/or that confirmation email.
I share concerns about JS browser encryption. ProtonMail has the benefit of native open-source iOS and Android apps which circumvent this issue for those uncomfortable with browser encryption. Since Discourse is pure webapp, it’s a different challenge.
The older conversation above implicitly shifts across multiple perspectives. It would seem important to make these explicit.
###Threat Model
###Messaging Model
It may simply be that OpenPGP.js is fundamentally unable to perfectly solve Threat Models 1 and 2. It’s also my understanding that PGP is cumbersome and not designed for Messaging Models 1 and 2 (though it could probably be imposed to some effect).
Extending Discourse app to support PGP would seem to perfectly answer Threat Model 3 and Messaging Model 3. This is how Facebook’s OpenPGP system and the WP plugin function. Facebook’s implementation does not rely at all on JS (the WP plugin may, I don’t recall).
I suspect there are good reasons Facebook uses Signal Protocol for encrypted messaging and PGP for notifications.
In my preferred realistic scenario, Discourse would implement Messaging Model 1 and protect to Threat Model 2. But I think this scenario requires implementing PGP and something like Signal Protocol. In terms of my priorities for my Discourse install, I’d be super happy with a PGP solution for Threat Model 3 and Messaging Model 3.
What I have instituted thus far is a Group and Category which automatically adds anyone signing up with a ProtonMail domain, or our custom domain (which uses ProtonMail). From there, we can discuss the ins and outs of these questions with a self-selected group of encryption-aware users. That could be one other way for admins to avoid instilling a false sense of perfect privacy.
Of course, I don’t have much to say on the practicality of implementing any of this, and we don’t have a budget to underwrite a plugin, so…
I’m just gonna leave that there ↑
Yes, I read that article when it first came out.
Meanwhile, ProtonMail is amassing millions of users while being transparent about threat models and using PGP and OpenPGP.js in ways others haven’t – demonstrating that even pretty good ideas still require smart implementation.
It’s not surprising that Zimmerman was able to solve a math and programming problem while simultaneously being unable to solve the social dynamics of adoption and implementation. That’s not to his discredit; the problems merely exist in different domains.
ProtonMail and Signal have both achieved whatever success they’ve achieved by seamlessly integrating the encryption – much like SSL, TLS, and other protocols which don’t rely on manual key generation and exchanges by end users.
The problem with PGP traditionally has been the barrier of requiring 2 end users to jump through a bunch of hoops to get anything working. With Facebook’s implementation for notifications, only one end user is required to get it working. This changes the dynamics of adoption significantly.
And I also realize that most people simply don’t care, and that we can all come up with reasons to persist in plaintext world. Some people actually like the idea of Google reading their emails and ISPs selling browsing history so advertisers can sell them more stuff.
I remember reading a while back that the Discourse team had a reasoned argument for relying on email for unique user identification and notifications. Email is increasingly seen (by “the public”) as antiquated, but I can understand the arguments for email. What’s harder to understand is: If (A) email is a given, and (B) “let’s encrypt everything”, then © keep email notifications plaintext. If PGP isn’t the solution, what else resolves those mutually-existing conditions barring Sam’s option 1 where better encryption simply becomes pervasive at the meta level of the internet?
Not totally sure what you are getting at, but @falco has on his page for 1.8 a “no leaking content through email” mode for Discourse. It turns emails into notifications only with zero names or any other kind of site content leaked through email.
