hmerritt / discord-encryption Goto Github PK

Is there any way to contact you besides this? I'd like to have you on my contacts so i can ask questions about this and report bugs real time.

Hi there, it seems you've taken the same interest as we ( as a group ), have.

If possible, we'd like you to join our team as we could use someone with the same ambitions as us to implement a general encryption plugin for Discord.

If you'd like to see our work so far, check it out here: http://gitlab.com/leogx9r/DiscordCrypt

( We don't use GitHub due to their highly restrictive abilities and infringement on user privacy. )

If you'd like to contact us, please join our Discord server. ( https://discord.gg/3uakNmM )

Title says it all. I'm using BetterDiscord on Manjaro KDE.

Whenever someone on my Discord types something with my lock & password it won't show as plaintexyt, it shows as the hash, When i use the correct password and green lock it returns me with the hash, U have tried disablingm enablingm restarting, Nothint works.

Here is a video showing that i can't even change the passphrase nor diable lock. It's stuck.
https://s3.amazonaws.com/img0.recordit.co/YnjGyakwbz.mp4?AWSAccessKeyId=AKIAINSRFOQXTN4DT46A&Expires=1532508544&Signature=SXqiyZo7%2Bi2nr8WaUEkpxEbIWUA%3D

Everyone has correcy password, at one point i could't even click myself off from green lock, I'd love to have tome help. Thanks!

After using the plugins for some tests I have noticed a few things that are not standard practice and are possible security vulnerabilities.

Missing key exchange

The plugin lacks an key exchange algorithm like DH.

Key generation

export const encrypt = (msg: string, channelData: UserData["global"]) => {
  const key = crypto.SHA512(channelData.password);
// ...

Why do you use 512 as key and not 256 (since we use AES-256)? You probably think more bits = more security but it's not working like that.
Indeed OpenPGP RFC 4880 section 3.7.1.1 states:

If the hash size is greater than the session key size, the high-order (leftmost) octets of the hash are used as the key.

So if crypto-js implements this correctly you basically use only half of your hash.
Solution: const key = crypto.SHA256(channelData.password);

However this approach has the following problems:

1. Using the same key for different user will produce the same hash
2. SHA256 is extremely fast (SHA512 is even faster), there is no additional brute-force protection
3. No protection against ASIC

Better solution: Use a key derivation function (pbkdf2, argon2, scrypt). This algorithms are hardened against attacks and the same input wont generate the same key.

Static IV

Using a static IV is not recommended. The code is probably vulnerable to Padding-Oracle attacks (assuming crypto-js uses AES in CBC mode since you use an IV but the code uses no auth tag).

• Using a static IV will generate the same ciphertext which gives an attacker information

Solution: Use random bytes as IV. The other side must know the IV so you have to tell them. AES follows Kerckhoffs's principle

The principle holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge

This means it's completely fine to send the IV in plaintext. It is not possible to break AES for an attacker knowing the IV.
Example message: IV/ciphertext or IV%ciphertext or IV@ciphertext

MITM

The code does not verify the authenticity and integrity of the ciphertexts. This results in treating every received message as if it definitely came from the sender. However, an attacker could intercept and manipulate the message on it's way to the receiver.
Solution: Use AES in GCM or CCM mode. This will produce an auth tag which behaves like a signature. The receiver can check that the message has not been manipulated.

Right know in it's current state I won't recommend using this plugin for encryption since it violates standard principles.

its again the same problem

Kindof an issue but not too much more like a request

I notice that it only decrypts when a person sends a message. however im in a big server and it doesnt like to be cluttered so i was wondering if this could maybe be added?
(Edit)
Maybe a suggestion is to make it decrypt everytime we click enter so we can manually do so? im not a js programmer so i cant really understand how you could do it but it would be nice.

https://github.com/Hmerritt/discord-encryption/blob/a561a63e77256b451222ad5ed6035e95dbe12c69/encryption.plugin.js#L10-L13

This is a terrible practice.

• It puts away code that is a part of the plugin on an external source which hinders proper reviewing.
  (breaks one of the key reasons of why open source exists)
• It hides the intention of what those scripts are supposed to be doing.
  (missing documentation, and the scripts are hosted behind personal domains, instead of a well known cdn)

BetterDiscord has faced issues in the past with 3rd party plugins stealing tokens and performing other malicious activity.

As such, I think transparency and security are important concerns if you are releasing a plugin.
I initially debated submitting a pull request to fix these issues myself, but decided that it might make more sense to me if I made my own end to end discord encryption plugin from scratch, to fix some other issues along the way as well.
However, given that this plugin has gained some attention, I request the owner to fix these concerns anyway.