Would it be feasible to potentially build in a secure encrypted PGP messaging system and/or encrypted chat into Discourse or have a plugin for individual installs? I really like https://encrypt.to and it could potentially be built into Discourse somehow since it’s open source and hackable etc.
Are there any plans for such features now or in the future? It would definitely be a good selling point if all messages (like PMs etc) were encrypted and real-time chat/hangouts were definitely private and secure. With encrypt.to you could make it so a pop up box on the bottom right could send a message to someone’s email using their public key for encryption. You could either have the user copy and paste or import the recipients public key or have the recipients store their public key in their Discourse account securely and then all PMs are encrypted then sent to email that way too.
Obviously there are a ton of ways of doing it but I thought it would be a cool feature to have. I would definitely be interested in developing this myself (with some help from the Discourse community of course;) if need be.
Any reason standard HTTPS support is not sufficient? Or is the encryption to hide the messages from the Discourse site owner, who has access to the database?
Hello and thanks for your reply Jeff, I really appreciate it.
I guess it would serve the purpose of private messaging where even the admins don’t have access to the content, but that is just one reason. You could make it so that only the recipient handles their public key, which is stored in their account securely, and other users don’t have access to that too which is really nice and keeps your key private. I think it’s better that way instead of using public key servers. None of the message would be stored just PGPd and sent. It wouldn’t even take that much extra space since public keys are so small. Mine comes in at a few KBs.
The more security the better imho. This would be a nice feature to have but that is of course up to you and the community. It would definitely be a unique selling point for a platform like this. I know it’s not just about selling points but for users especially in hostile countries it would be a great way of securing messages. Most (failed) countries, like Syria, make SSL and port 443 illegal so using just https does have some downsides. Also, admins having access to the database could be fatal too. It would be easy to spy on, or at least could potentially be, if the database was hacked or subpenaed. If messages were fully encrypted with PGP and the whole feature implemented correctly I think you have a platform with strong internet freedom and free speech tools built in. It could prove quite useful for journalists and even organizations with heavy compliance standards.
Maybe it’s too next-gen, idk, but I think it would be cool for sure. Do you think it would be doable or too much of a shift? I’d be happy to do the grunt work on it myself, np.
correct me if i am wrong but for B to encrypt a message so only A can read
B have to encrypt the message with A public key. and only A can read it with his private key.
This sort of encryption system, is good for a message from A <-- --> B
but not from A --> B , C & D
(unless a trusted group (A,B,C,D) knows the private key and they are using encrypt/decrypt with it )
You(A) would have to encrypt and store the same message multiple times for every user(B,C,D) that is allowed to see it .
The server will have to serve different content based on the user public key.
This sort of thing could work on a small scale, on for a particular usage ( private messages ), but will not be suitable for larger scale communities usages, with some exceptions.
Another challenge will be to integrate the actual encryption/decryption on the client side.
that imply that external tools are required potentially a browser plugin. https://webpg.org/docs/webpg-userdocs/
Would have to be a plugin, totally for having something like it but getting key sharing going is complex. Would be intersting for sensitive political forums in say china or whatever.
What I had in mind was strictly person to person (one to one) messaging. For one to many, since each recipient/user stores their own public key, maybe you could have a box of recipients that you tick each one to send the message to and each user is sent the message with their own individual key decrypting. Maybe just a simple implementation would suffice. It could just be the one to one applied to one to many instead of thinking in terms of posts and sharing etc.
Having something like this might be a little complex but I would be happy to devote some time to it and send it to the team when properly baked? If you give me the green light I’ll could get started on it right away? Maybe we could exchange PGP public keys so as to purify the content creation life-cycle somewhat, lol? Information security starts with secure coding practices,
Awesome! Any suggestions as to coding languages, tools, etc.? Are there standards established or in mind for how plugins should be created and/or handled?
A JavaScript implementation of PGP actually already exists in the OpenPGP project.
However, if a plugin on this or a similar foundation were offered to me, I would refuse to use it. I barely trust my browser not to reveal the few stored passwords to any JavaScript that asks; I would never entrust a JavaScript with private key material.
If you want secret, encrypted and strongly authenticated communication, send GPG encrypted emails. Thunderbird with Enigmail makes that really easy.
There is a market though for people who do trust javascript, see clipperz or lastpass, I believe further down the line ecmascript will offer a solution for the trusted javascript problem.
That’d work, but notice how it provides mechanisms to prevent secret key material to be exported back into JavaScript and even warns not to expose key material that wasn’t explicitly created through the JavaScript API…
@n30, I’m not worried about the server backend; this is about trusting the JS app to handle private key material and guard it against remote script injection attacks. Or simply a compromised admin account.
Who said it was a JS app? The private key would only be handled by the users own PGP client on their private system after the receipt to their private email address. Like Thunderbird with Enigmail, which I proudly use. I’m thinking the https://encrypt.to API is the way to go, which may or may not use JS, we’ll see.
G’nite all and thanks again for everyone’s comments and for being civil
+1
So if I send a message via Discourse’s JS frontend in the browser, it cannot be signed; and when I receive an encrypted message through Discourse, I must read it in my email client…?
By the way, enrypt.to is based on the very same OpenPGP I mentioned earlier. They encrypt to public keys with a given key ID but do not sign the message. Also, that key is loaded from a public key server – which has its own share of problems…
This would be separate from Discourse core and only a plugin so it’s not going to replace anything in Discourse core. What it could do is allow certain Discourse installs that are especially concerned about privacy and security to incorporate a secure PGP enabled messaging system. Like encrypt.to, who’s public keys don’t have to be from a public key server but can be uploaded by the individual, and then the message is encrypted with the public key on the fly and then forwarded on to the users email address (since SMTP email messaging is already included in Discourse) to be read and decrypted by the users PGP client on their personal computer. Also, there are ways to use PGP with Gmail in the browser too but that is up to the user.
I use encrypt.to quite a bit but my public key (which encrypt.to ONLY handles public keys not private keys. If you think of the way PGP works it makes sense.) isn’t on a public key server and we would only need the module that is used to store the users public keys and encrypt with the public keys. We may only need that last part and build a small encrypted public key server file storage module separate from that and then just incorporate encrypt.to to encrypt and then the already built in SMTP email messaging system to send.
Obviously if users are using an email/SMTP messaging service like Mailgun they will need to keep in mind and account for the amount of messages that will be sent using that service, unless they have setup their own email server (which would probably be ideal but still may have limits with hosting and bandwidth usage).
Have a good day all and thanks again for the feedback. It’s all really helpful and useful.
Sender composes a message to recipients but no draft is stored on the server.
Sender’s UA receives PGP public keys from Discourse.
Sender encrypts the message for the public keys received above.
The encrypted message is submitted to Discourse.
Discourse relays the message to recipients’ email instead of storing it as a PM.
Please correct me if I misunderstood and didn’t get this right. But as it stands, this has two major problems.
For one, your messages still won’t get signed. Encryption without authentication is bad. An attacker can gain knowledge about your private key by crafting a special message and learning whether you could successfully decrypt the message or not. Granted, this is a theoretical concern in this case. But when it comes to cryptography, “good enough” is dangerous.
Secondly, this is only as secure as the integrity of the Discourse installation and its SSL transport layer encryption allow. An attacker with control over the server or a man in the middle can modify the public key set handed to the sender, and the sender cannot independently validate the keys it received from Discourse.
Bottom line, users must still trust in the integrity of the Discourse server and the security of the SSL transport layer encryption; the only additional security gained is that an attacker cannot retrieve old messages from Discourse’s database, but you don’t need PGP to achieve that…
I appreciate your comments Tom (and absolutely love your profile pic;) You mentioned that, “it requires FULL trust of the forums admins.” Doesn’t that apply already, at least some degree, to the existing site? Couldn’t you say that about any forum and any social net? The very act of storing and/or doing anything online could be seen as a trust issue (in a more general sense I suppose).
Also, “The biggest danger is that people will be given a false sense of security.” Couldn’t you say that about any security mechanism, software or otherwise? There is no 100% secure anything and no such thing as guarantees which is one of the first things you learn as a security researcher/ethical hacker but that doesn’t negate the need for more secure means of communication and more secure software/hardware and the people to create them. Just because something/anything could be compromised doesn’t’ mean it shouldn’t be used, and by your definition trusted, at least to some degree or another. In other words the very act of coding could mean you’re introducing vulnerable/hackable code but that does NOT mean you shouldn’t code.
Is that the gist of it? I guess I don’t see anything fundamentally wrong with a secure PGP messaging system as a plugin for Discourse, depending on how well it’s implemented of course. Unless you know of something specific that’s fundamentally wrong with it? If you do I hope it’s code that I/we can avoid in the life-cycle creation process of this plugin.
Thanks again Tom, and everyone, for your comments and concerns. I really appreciate it and wish you all the best.
That’s precisely @tmthrgd’s – and my – point: if your encryption feature does not protect the user against an evil server, then it is fundamentally broken from the very start. Without your encryption feature, messages are compromised if the server is compromised. With your encryption feature, (new) messages are still compromised if the server is compromised.
Sorry, but that is metaphysical bull****. If you want to code just for the sake of writing code, go write Towers of Hanoi in every programming language ever invented.
We’re not even arguing whether you should or should not shoehorn PGP into Discourse’s JavaScript frontend. We’re arguing whether it is or isn’t acceptable to advertise this as a security feature to other users – and as has been explained at least thrice now, no, it isn’t.
Neither do I. PGP is a great encryption protocol. But for all that is good and holy, you cannot with good conscience implement it in JavaScript in a webbrowser. If you really want to do this, write a native-code plugin for the three most popular browsers that implements an interface to native GPG for JavaScript. Getting this right will still be hard, and since it’s native code, programming errors can lead to remote code execution, but that’s still a more worthwhile project then the other approach with JS-PGP in the browser.
I understand you, and everyone’s, point and appreciate the comments.
Just so you all know I never intended on using Java for this at all. I
think that’s where my confusion was for a second. I would prefer to do
this in Ruby, Python or even PHP but definitely not Java. I never stated
I’d like to code it in Java and now I definitely know why so thanks for
pointing it out all.
(I actually hate Java as a security researcher/pro because there is a
new vulnerability disclosed every freaking week.)
I’ll definitely keep everyone’s thoughts/comments and concerns in mind
moving forward. This is in a very early stage of dev so it will take
sometime to find the right recipe before putting it into the oven, so to
speak;)
