Discourse Encrypt (deprecated)

[Discourse]

discourse-encrypt is deprecated, and support will be dropped in Q1 2025.

We’ve taken this decision based on the very low adoption rate, and high maintenance costs for such a complex feature.

To aid migration away from the plugin, two new settings have been introduced:

allow_new_encrypted_pms (default true) - disable this to prevent users from creating new encrypted messages

allow_decrypting_pms (default false) - enable this to show a ‘decrypt PM’ button at the top of every encrypted message, and also enable the ‘bulk decyption’ button in a user’s “security” preferences.

Server administrators can check the number of encrypted messages remaining by running this command on the console:

Topic.joins(:encrypted_topics_data).count

To print a more detailed list of topic-ids and participants, use this command:

Topic.joins(:encrypted_topics_data).each{|topic| puts "#{topic.id}: #{topic.topic_allowed_users.map(&:user).map(&:username).join(', ')}"};

Original Plugin Description

	Summary	Discourse Encrypt enables private, encrypted messaging between end-users. All sensitive information is stored securely on the server and is encrypted and decrypted only on the client-side.
	Repository Link	https://github.com/discourse/discourse-encrypt
	Install Guide	How to install plugins in Discourse

As this is an official plugin maintained by the Discourse team, Support, Bug, UX, and Feature requests can be made in the respective categories here on Meta, and tagged with the appropriate plugin tag. Click on a link below to get one started.

 Support  Bug  UX  Feature

Three easy steps to use this plugin

1. Enable encryption and activate current device.

2. Send an encrypted message. The recipient must also have enabled encryption.

Optionally, you can determine the time after which the whole message or specific post will be permanently destroyed

3. Read secret messages. Encryption must be activated first to read them.

^{Note: In this example, the user was prompted for paper key again because encryption was deactivated (by logging out or explicitly deactivating it from preferences screen).}

Technical information

This plugin gives users the possibility to communicate securely through Discourse, by using an end-to-end encryption scheme. Most of plugin’s logic is implemented on the client-side and the server-side handles only public or encrypted information. It does not encrypt any post metadata, such as names of participants in the conversation, posted time, likes, small actions, etc; uploads are encrypted, but their presence is not because the system must associate uploads with posts to prevent deleting them.

The whole code is open-source and security enthusiasts are welcome to review it. For any further information, do not hesitate to contact me or the team.

read more...

Summary

The goal of this plugin is to offer integrity and confidentiality of the encrypted contents, and to protect it against information leaks and unauthorized users. The following sections describe the usual operation mode, used algorithms and threat models.

To use this system, users enroll once by generating a “user identity” consisting of two 4096-bits RSA keys, one for encryption and another for signing. Users can export their “identity” for safe keeping or store it on the server, encrypted after generating a paper key. These two methods serve as backups or are used to enroll new devices.

Paper keys (inspired by RFC 1751 and BIP-39) are human-readable keys that are used to securely store the “user identity” on the server. A paper key consists of 12 random words, picked from a list of 2048 words, offering 121-bits of entropy (the first word is used as a label). To encrypt the “user identity” with a paper key, the system will first derive the encryption key using PBKDF2 to stretch the paper key into a 256-bit AES-GCM key.

Creating an encrypted post

To create a new post, the user (their browser) will:

1. sign the current post content using their private signing key;

2. generate a new “topic key” (a AES-256-GCM key) - which is going to be used to encrypt the post, some post metadata and the title of the new topic (if available);

3. fetch the public keys of all participants and encrypt the “topic key” for each of them;

4. send to the server the encrypted post (Base64 encoded) and the encrypted topic keys (also Base64 encoded) of each participant.

The pseudocode for the encryption operation would be something like:

signature = rsa_pss_sign(current_user.identity.sign_key.private, post.raw) # 1
topic_key = topic.key || generate_aes_256_gcm_key() # 2
encrypted_title = aes_256_gcm_encrypt(topic.title, topic_key) if topic.blank?
encrypted_post = aes_256_gcm_encrypt(signature + post.raw, topic_key)
encrypted_topic_keys = recipients.map { |r| rsa_oaep_encrypt(topic_key, r.identity.encryption_key.public) } # 3
$.put("/posts/create", { title: encrypted_title, raw: encrypted_post, keys: encrypted_topic_keys }) # 4

Reading an encrypted post

To read a post, the user (their browser) will:

1. fetch the encrypted post payload (post plaintext and signature) and encrypted topic key;

2. use their private encryption key to decrypt the encrypted topic key;

3. use the decrypted topic key to decrypt the encrypted post payload;

4. fetch the public signing key of the poster and verify the post signature.

Algorithm Suite

This plugin makes extensive use of the cryptographic primitives implemented in Web Crypto API, which are available in any of the modern browsers Discourse supports (except Internet Explorer).

• getRandomValues PRNG: It generates paper keys and 96-bits random IVs.

• PBKDF2: It stretches the 132-bit paper keys to 256-bit keys, used for encrypting “user identities”.

• AES-256-GCM: Used to encrypt each post’s content. It also offers authentication by producing an authentication tag of 128-bits, but this is a less important aspect because posts are verified using a signature generated by the poster (see step 1 above).

• RSA-OAEP: Used to encrypt “topic keys” and “user identites” for safe-keeping on the server. All RSA-OAEP keys are 4096-bits long.

• RSA-PSS: Used to sign each post’s content for verifying authenticity. All RSA-PSS keys are 4096-bits long.

Primitives

The system uses a set of primitives built on top of those provided by the browser via Web Cryptography API.

• encrypt and decrypt: Used to encrypt and decrypt post contents. encrypt takes a JSON, an AES-256-GCM key and a RSA-PSS public key and outputs a single Base64 encoded string; decrypt takes a Base64 encoded string and an AES-256-GCM key and outputs the initial JSON object;

• verify: Used to verify post contents after decryption;

• exportKey and importKey: Used to export and import “topic keys”;

• exportIdentity and importIdentity: Used to export and import “user identities”.

Types of keys:

• topic keys (AES-256-GCM)

  • used to encrypt each post in a topic (posts are individually encrypted)
  • are generated per topic, on the client-side by the original poster using WebCrypto’s API generateKey primitive
  • are encrypted with user’s public key for every user that has access to the specific topic using WebCrypto’s API wrapKey primitive
  • are stored (encrypted) on the server-side for each user in PluginStore

• RSA key-pair (public and private keys) (RSA-OAEP and RSA-PSS, 4096-bits)

  • used to encrypt all topic keys a user has access to
  • are generated per user on the client-side by the original poster using WebCrypto’s API generateKey primitive and shared amongst all of user’s devices
  • server-side: public identity is stored as exported by the client, but the private identity will always be encrypted with the passphrase key
  • client-side: public and private keys are stored as CryptoKey in IndexedDb; if not possible, it will use window.localStorage (in Safari)

• passphrase keys (derived using PKBDF2 with 128,000 iterations)

  • used to encrypt “user identities” for safe storage on the server
  • derived from a paper key (or user’s passphrase for legacy purposes)

Threat models

Compromised Discourse Instance

An attacker which can inject code could in theory access encrypted information by serving malicious code, which decrypts the encrypted content and sends the plaintext posts to another server. To make this possible, it is enough to have access to an administrator account and create a theme component with the malicious code.

Default protection mechanisms such as CSP can detect and mitigate Cross Site Scripting (XSS) attacks that could also represent a way of injecting malicious code.

Man-in-the-Middle Attack

In Man-in-the-Middle attacks, the attacker intercepts the communication between the user and server, giving them the ability to read or alter it. Because the plugin encrypts everything before sending, an attacker cannot decrypt anything by simply eavesdropping. Similarly, because information is authenticated the attacker cannot alter it.

However, the attacker could serve malicious code back to the user and follow a similar attack to the one presented in the previous section. This is partially mitigated by HTTPS, which is considerably reducing the attack probability.

Notes

The plugin already has a little history and that can be seen while browsing the source code and noticing the two implementations of the protocol v0 (initial, alpha-beta release) and v1. Protocol v0 is no longer used to encrypt new posts, but kept to continue decrypting old ones. New protocol includes authenticity of the ciphertexts and all posts are signed with the private key of the poster.

Other Resources

• Original spec for this plugin on Meta’s Marketplace

Last edited by @david 2024-12-03T15:46:08Z

Check document

Perform check on document:

[jrgong]

How can I enable sending encrypted messages to groups? All users of the group and the message sender have encryption enabled, but I still get error message:

“You do not have permission to send encrypted messages to groups.”

[JammyDodger]

I don’t believe it’s currently possible to send encrypted PMs to groups.

[Heliosurge (Dan DeMontmorency)]

Does this mean that group mailbox becomes broken? and/Or inviting a group to pm would not work?

[jrgong]

This, it wasn’t possible in the first place.

[anon48433008]

Do I need to submit a bug report on this being broken?

Encrypt plug-in issue

I seem to have an issue with the encryption plug-in seems to be twofold First I noted I could read a PM from my transactional email service [test] So I sent that test message to someone who recently just had to reactivate their encryption, they lost their key, so I feel confident they do have it working It can be read, I didn’t think that was possible As I had set up a second account today to test a different setting I decided to log into that and send my own Here’s the second thing This…

Everything appears active short missing the normal lag in opening but PM’s are not encrypted

[JammyDodger]

There’s no need to cross-post, but if you’d like to make it a bug report rather than a support request you can follow these guidelines and then recategorise it - Writing an effective bug report

Though it’s worth noting that both bug reports and support requests can take time to pick up traction, especially at the weekend.

[david (David Taylor)]

Unfortunately due to the relatively low adoption rate, and high cost of maintenance, support for discourse-encrypt will be dropped after core’s next stable release in Q1 2025.

The original post of this topic has been updated with more information, and we’ll be introducing an automatic warning for admins of affected sites.

[cmdntd]

Hope for dev this on future.
This is very important/useful one in data/blockchain/security.