Shared secret encryption plugin

[warcode]

While waiting for a true OTR solution a simple shared secret symmetric encryption set by the users themselves would probably be "good enough" for most use-cases where you just want confidentiality for the message contents.

I have started a plugin at warcode/rocketchat-sharedsecret and the basic functionality is there.

The users should be able to set their key with either a slash command or as an option. This would optimally be per-channel. If you know the key, you can see the messages.

Will this work with the current plugin system?
Is it possible to assure that this will run last on save (and first on restore, if needed)?
Which event should I bind to for decryption in this case?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[engelgabriel]

Looks like a good start! I didnt try it on my local version, but on the high level seems to be the right way to do it.

[engelgabriel]

See #36

[warcode]

The plugin is now usable with a /setsecretkey KEY/off command. If a key is set the plugin will currently encrypt and decrypt messages with that key in all conversations and channels.

Messages and urls are encrypted.

As far as I can see there is no way to do encryption clientside and the keys have to be stored in memory on the server. This is still a step up from saving them in the db.

For now the encryption seems to break the oembed plugin and possibly others.

[engelgabriel]

@RocketChat/owners ideas?

[rodrigok]

Maybe we can disable the oembed plugin in encrypted messages

[Sing-Li]

As far as I can see there is no way to do encryption clientside and the keys have to be stored in
memory on the server. This is still a step up from saving them in the db.

Do we not use localstorage somewhere in the code base?

@warcode - do you speak XMPP?

[warcode]

The key is saved in localstorage on the client for decryption. The issue is that the saving of the message, and 'beforeSaveMessage' is ran individually on the server and client, the server version overriding the client one once that runs. This is standard procedure in a meteor app, but not helpful in my case.

@Sing-Li Not enough to confidently say I do.

[Sing-Li]

Are you saying that you can work with a 'beforeSaveMessageClientOnly' hook?

Sounds like a big security hole - but then we must trust our published packages since they are really part of core, just componentized :) OTR might not be possible without (something similar to) it.

[warcode]

We would need a hook that fires before the server method sendMessage is called, or wherever it is we are before we transfer the message object to the server. (I haven't had time to look through the code for that yet)

Right now a user has to trust the server to not listen in on the message before it is encrypted for storage in mongodb. If we can do a pure clientside encrypt/decrypt we are better off.

But of course the server can still add a plugin that listens in on the messages again before they are encrypted on the client, or simply fetches all the encryption keys from localStorage, but at some point you do have to trust the server somewhat in a web environment.

[k0nsl]

This is almost exactly what I've been looking for. I will test it.

[marceloschmidt]

@warcode I have tested your solution and it looks awesome! there are a few things I'd change, but I can do that after we accept your pull request, if you're willing to make one. Thanks!

[warcode]

See notes in pull request.

[ninja-]

honestly I would just stick to the "trusted server" model. the xmpp-otr or even tox-style madness isn't worth it

[cesarve77]

+1

[mikonoid]

How to install this plugin and enable ?

[computerinfo21]

@mikonoid See http://stackoverflow.com/questions/34806974/how-to-enable-encryption-in-rocket-chat where @marceloschmidt gave the command to run to add it. You will want to download the source, run the command, and then build it. Both of those steps take a while.

[engelgabriel]

@marceloschmidt and @warcode should we close this now that the OTR is implemented?

[marceloschmidt]

@engelgabriel this has been implemented, it's just not active in our Demo... I think it's OK to close this issue, but let's write a doc explaining how to use this sharedencryption plugin.