3 ms·
I only feel safe using end-to-end encrypted chatrooms. Currently, niltalk can read every message. At the very least, AES encrypting messages by the chatroom's
by 8rian 11y ago
I only feel safe using end-to-end encrypted chatrooms. Currently, niltalk can read every message. At the very least, AES encrypting messages by the chatroom's password will reduce reliance on SSL. But it really should use public key crypto for a key exchange between users. This is what's done by other disposable chatrooms:
https://crypto.cat/ https://crypto.cat/
https://ephemeral.pw/chat/ https://ephemeral.pw/chat/ (Also written in Go)
- hurin 11y agoThe problem with end-to-end encryption is not the encryption but the key-exchange (and especially so for multi-user setups). If you are trusting the server to create or associate identities with keys, the end-to-end encryption is easily subvertible.
- 8rian 11y agoNew keypairs would be generated on the client every time you join a chatroom. Another member of the chatroom sends you the shared_key encrypted by your public key. Server knows nothing, stores no keys. Keys exchanged between users. Javascript crypto is still a problem though: http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ When you re-download the codebase on every use, there is no way to ensure integrity of the code. This is the reason cryptocat ships as a chrome extension, because it is downloaded once. Even with these issues, I'd take javascript crypto + open source over nothing (or just SSL).
- hurin 11y ago> New keypairs would be generated on the client every time you join a chatroom. Another member of the chatroom sends you the shared_key encrypted by your public key. Server knows nothing, stores no keys. Keys exchanged between users. The question is - how does the first public key exchange happen? It has be done outside of the site for it to be secure and your private key must exist locally on your device - which is contradictory to the premise of these websites.
- soft_dev_person 11y agoIt's asymmetric encryption. Even if the server got a hold of the public key, it would not be able to decrypt the contents. How to ensure the server doesn't get a hold of the private key is the issue (can you really trust the code you're running?).
- StavrosK 11y agoThe bigger problem is "how do you ensure that the public key the server sent is actually the other user's, and not a MITM?".
- hurin 11y agoExactly, you have to exchange public-keys via another method - which is also potentially vulnerable.
- TheSisb2 11y agoUse keybase.io
- c22 11y agoBut all forms of exchange are potentially vulnerable, the point of using multiple channels for authentication is to increase the challenge-space for potential attackers. Indeed the chief benefit of public key encryption is that the key can be exchanged over a multitude of channels and a compromise of just some of them does not jeopardize the entire operation. Perhaps we need more authentication systems where this is made implicit, with trust based on the number of different mediums the key is transferred over (or the number of different third party signers).
- deleted 11y ago[deleted]
- thwarted 11y agoIs there a chat system that leverages keybase.io?
- ParadoxOryx 11y agoIIRC, PGP is not good for instant messaging.
- Sir_Cmpwn 11y agoPGP is acceptable for exchanging a symmetric key, though.