Discourse Encrypt (for Private Messages)

plugin
#21

I think there needs to be some sort of reset process. Just because having a user who has to abandon their account over a forgotten encrypted pm seems, excessive. :rofl:

I honestly favor a semi-destructive key reset method because it is simple to change keys used in future and not have to edit (much if any) previous data. In most encryption systems, a valid member key should still be able to access old data and the new key will only be valid for new communication.

I do support some sort of two party confirmation system for it. Itā€™s a ā€œdestructiveā€ action so should be at least moderately guarded. In my mind the flow could go something like:

User Requests Key Reset via Site
Staff(?) Confirmation of Key Reset Request via Site
Email Keyed Final Warning/Confirmation

@justin Yeah if you forget your password a lot, youā€™re gonna have a lot of unreadable encrypted messages. I think thatā€™d be inherent in the system.

@Stephen Yeah the topic keys change it a bit, and Iā€™m not that familiar with topic keys vs multi key systems. I think a system that doesnā€™t allow recovery of lost key data is inherently more secure even if less convenient.

My main example of this practice is a service like ProtonMail. With a recovery email and the confirmation from a staff member via your request, you can reset the main encryption key passphrase for your account. It will invalidate all the contents of every sent or received message, even if the mailboxes are encrypted seperately from the account, because the keys are nested like they are here, with private keys ā€œinsideā€ the public keys and sometimes multiple layers of this. The only data you keep is the to: from: and title of the email. There are many ways to approach this but I have a lot of thoughts on it and thought I would share.

2 Likes
#22

Where are you getting that from? They currently lose access to conversations encrypted with their previous passphrase, nothing else.

#23

What is the current reset process? Currently I donā€™t see any at all. I was sure it wasnā€™t the intended end functionality and was just making a slight joke about it while we were discussing it.

#24

This isnā€™t a for-production plugin, itā€™s the first iteration and at RFC stage, so itā€™s not ā€œfeature completeā€.

#25

Thanks for putting up with my bad joke. I realize it is very very early and was just inputting what could be designs and made a offhand joking comment while doing so. No intent to seem negative or detracting, my apologies if it came off that way.

#26

I think it is fine to let admins do a reset on keys if the user requests it

So the process would be

  1. User clicks reset my key, big warning pops up saying all encrypted content will be gone.

  2. Admin gets a reviewable and confirms it which triggers the reset

This though is a v2 feature, for now we should just have instructions on how to do this from the console

13 Likes
Discourse Keybase Proof
#27

Sam, would there be any way to extend this functionality to a category/threads (and allow by groups?)

I have a category that I need to see exists for purpose of board administration, but the topics inside should be confidential/private to the special work group who have access.

This would essentially give me the ability to provide a secure workspace for that small subset of users who I should not be readily able to read their conversations where with this plugin, they would have to constantly mix between normal and their workgroup PMs. Donā€™t get me wrong, Iā€™ll take this plugin for sure. But the encrypted thread option would be a game changer. For me and Iā€™m sure a bunch of other admins who want to hide certain category content from themselves for business teams use.

If this functionality were added that would encrypt a category, it would solve my needs.

Or, I can cover the category topics summary on the main page via CSS like I have now so I donā€™t see thread titles, and then you could make the threads encrypted upon creation by default for threads within a category. I think this would be easiest.

Only the admin(s) could turn on/off the category setting: allow encrypted threads within this category.

Please, oh please can you add this to your list of cool stuff you might do?

1 Like
#28

Absolutely not, this is not in scope and not planned even 3 iterations out.

Messages are encrypted using an encryption key for the topic. This encryption key is encrypted using the public key of end users.

The server only knows:

  • there are a bunch of blobs of random data in this message.
  • there are a bunch of other short blobs for the message (which are topic key encrypted using various user public keys)
  • certain users are allowed to get the blobs and add blobs

Even group support in messages is something that will not happen, groups are fluid, so you need to be explicit about which users are allowed access, otherwise when you add a user to the group some end user is going to have to encrypt the topic key with a public key of the new user, server has no control over when this would happen.

I can not think of a way to have ā€œencrypted categoriesā€ due to the fluidity of groups.

12 Likes
#29

Overall, what the summary post needs is a threat model. If users Alice and Bob are communicating, from whom exactly are we trying to secure the data? Are we trying to ensure that non-administrator moderators canā€™t read the posts? That Discourse administrators canā€™t read the posts? That the site owners canā€™t read the posts?

As you admit, whoever controls the JS can ā€œwiretapā€ the keypresses and send the the unencrypted plaintext back to the site owners. So from whom, exactly, is this software intended to defend?

Fundamentally, if Alice and Bob want to communicate with encryption, and Eve is attempting to eavesdrop, Alice and Bob cannot allow Eve to provide the encryption software. If Eveā€™s running the website, then Alice and Bob have to trust Eve in order to use her code on her website.

As a result, the web just doesnā€™t support end-to-end encryption without trusting the web server.

The initial post attempts to draw a distinction between a ā€œcompromised serverā€ where the attacker has ā€œfull accessā€ over the web server, a MITM attack where ā€œthe attacker can read and alter every communication,ā€ and a ā€œbackdoored serverā€ where the attacker gains access to the server hosting Discourse. I donā€™t see the distinction here, and I fear that youā€™re fooling yourselves into thinking that thereā€™s any real difference between these cases.

1 Like
#30

Setting aside the question of whether this feature works as intended, I would never want this feature on my business-plan Discourse site at all. Specifically, I would never want to install a PM feature that made posts unreadable to Discourse moderators, because that would mean those PMs couldnā€™t be moderated.

Anyone with a forum bigger than a certain size will have a certain number of users who will attempt to harass users over PM. Users need the ability to flag those posts, allowing moderators to step in and adjudicate.

The whole idea of this feature seems to run contrary to the spirit of Discourse, a home for moderated civilized discussion. Discourseā€™s core philosophy (I thought!) was that civilized discussion requires moderators, working hand-in-hand with their community.

E2E encryption is typically the domain of anti-moderation anti-censorship advocates, who believe that any two individuals should be able to communicate freely and privately without allowing anyone to interfere. As a result, E2E encrypted channels like Tor and Freenet tend to attract people whose speech comes under attackā€“not just the noble users like citizen journalists, but also spammers, child pornographers, and fraudsters.

We pay CDCK, Inc. to host our Discourse forum for our business; we make it clear in our forum guidelines that this is our forum, and in our house, we make the rules. We make it clear that our forum administrators can read PMs, and that users who wish to communicate outside of our supervision should use another channel.

What kind of Discourse business-plan customers would want a feature where they couldnā€™t read and moderate their own forum?

1 Like
#31

The intention is to protect conversations between members even from malicious administrators. This is certainly not the case for V1, but longer term an electron wrapper or browser plugin can provide that guarantee.

There is a reason this is a plugin and will never be a core feature. Not every Discourse needs or wants this.

It is very appealing for certain use cases:

  • Journalist forums where sensitive information is being shared between end users that have high enough trust to communicate in this manner

  • Internal company Discourse, where you want HR to be able to discuss stuff safely with various employees, or share passwords between small groups of users and so on.

For your site, yes, this makes absolutely no sense.

10 Likes
#32

Going one step further though there are potentially huge implications for site administrators using this here in the UK.

Section 49 of the Regulation of Investigatory Powers Act (RIPA) gives law enforcement the ability to detain and imprison anyone who refuses to hand over the keys to encrypted material. Two years for typical cases, five if the matter relates to child indecency or national security.

In most cases those terms are handed to the suspect, but systems owners have also been served under section 49 when it relates to data which is stored or transmitted via their systems, particularly if the end user account holder canā€™t be otherwise identified, or the account has been abandoned.

Itā€™s one of the reasons weā€™ve had so much luck rolling out managed encryption and taking away desktop admin rights- because if users canā€™t employ cryptography through our systems (such as enabling unmanaged EFS or bitlocker) we run a far smaller risk of being exposed under section 49.

Obviously enabling encrypted chats is a choice, hopefully nobody would be silly enough to implement it without fully understanding the above, or wait until a heavily audited admin override to access keys becomes a thing.

2 Likes
#33

This is certainly something worth proposing to NGI0 PET program or the OTF funding scheme (or both).

2 Likes
#34

Do we have these console commands already?

#35

Got to remember this is still in RFC state, stuff is expected to change prior to the first official release. I would be extra careful using this in production now, we are likely to be amending protocols in the coming weeks which can leave you with no clean upgrade path.

5 Likes
#36

Yeah itā€™s just playing around with, weā€™ve disabled it once but people wanting to mess around again. Even on a test server I have marked this experimental several times. I think itā€™s gonna be a good feature and weā€™re just interested in messing around and testing as it evolves.

3 Likes
#37

@udan11 can help with the console commands, but may take him a few days. We are busy iterating on the protocol here.

4 Likes
#38

Resetting current user keys is possible right now using the following commands in the Rails console:

u = User.find_by(username: "dan") ;
u.custom_fields.delete("encrypt_public_key") ;
u.custom_fields.delete("encrypt_private_key") ;
u.custom_fields.delete("encrypt_salt") ;
u.save_custom_fields

Replace dan with the username you want to reset.

In other words, these lines delete the custom fields that are used to store the keypair.

8 Likes
#39

That means this is out for paid hosting?

#40

From what I have seen, looks very positive :upside_down_face:

Will it be possible to change the text ā€œA secret messageā€ to whatever temporary topic title would be most appropriate (such as ā€œA secure messageā€) - the messages we will be sending are not really ā€œsecretā€ but need to be secureā€¦?