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.