Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add end to end encryption #8

Open
qoomon opened this issue Apr 18, 2018 · 5 comments
Open

add end to end encryption #8

qoomon opened this issue Apr 18, 2018 · 5 comments
Labels
enhancement New feature or request

Comments

@qoomon
Copy link

qoomon commented Apr 18, 2018

my suggestion each new client creates a private and public key and share the public key after this encrypt every message.

@marzavec marzavec added the enhancement New feature or request label Apr 19, 2018
@marzavec
Copy link
Member

I like the idea and a long while ago attempted to build a client with this feature- but the rate-limiting made it impractical to have group (3+) e2e (since the message needs to be re-encrypted & re-transmitted per client). Things have changed since then, so I'll keep the feature request open & in mind while rebuilding the client.

@qoomon
Copy link
Author

qoomon commented Apr 19, 2018

maybe this is a good starting point https://github.com/phutchins/pipo

@marzavec
Copy link
Member

The code isn't so much the problem, there are several proven libraries that can handle pgp- the main issue atm would be how the hack.chat server handles rate limiting.

Currently, for every packet that is sent to the server variable 'weight' is added to the socket, if that weight exceeds a set threshold the server rejects further messages until sufficient time has passed. For a chat packet, that weight is calculated based on length of text passed.

Ascii armored pgp data adds a good amount of extra length to a single message, which on a one-to-one basis (ie private messaging between two people) isn't much of an issue for the current rate limiting implementation.

However, if you add a third (or more) party into the mix; that's when you run into packets being rejected. A single message needs to be encrypted using the target recipient's public key, so if the same message is to be received by two people it has to be encrypted two different times using two different public keys. This then has to be transmitted twice as well, which quickly increases the chances of getting rate limited. Add more users to the channel and it becomes impossible for everyone to get the chat data.

There are a few possible ways around this problem and it will take some considering.

@crmepham
Copy link

1 to 1, private messaging would be a good start.

@pixl8dev
Copy link

That would be a good idea because you could create an account or something and add friends so you can chat one-on-one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants