-
-
Notifications
You must be signed in to change notification settings - Fork 224
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
Comments
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. |
maybe this is a good starting point https://github.com/phutchins/pipo |
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 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. |
1 to 1, private messaging would be a good start. |
That would be a good idea because you could create an account or something and add friends so you can chat one-on-one. |
my suggestion each new client creates a private and public key and share the public key after this encrypt every message.
The text was updated successfully, but these errors were encountered: