Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm a security noob and I've been thinking about writing an encrypted chat application with Node.js and Socket.io. I have the chat part already done, but not exactly sure where to proceed with the encryption part. I don't want to store data and I want the data that is being received and sent to be encrypted. I was thinking of having users enter a room together with the same key to use for decryption. This could potentially be something I use and I was also considering using SJCL. Am I totally way off in my approach to this...? Suggestions?


SJCL is good software and has good defaults for its high-level encrypt function `sjcl.json.encrypt`. It uses CCM so you don't have to MAC in addition to encrypting (as TripleSec does). Depending on what parameters and degree of safety you want for PBKDF2, you might wind up locking up the browser while your keys are being derived. It's hard to speed up this part of the encryption process because it's meant to be intentionally slow to prevent password cracking.

The biggest problem you'll have in building a secure chat app is establishing the connection in the first place. To do that, either the participants will have to share a secret, or there will have to be some sort of public-key based handshakes with certified public keys.


CCM is short for "Counter with CBC-MAC". I does also MAC the encrypted data and is equally slow as using a cipher and HMAC on top of it. A real speed improvement would be the Galois Counter Mode.


In my experience, speed isn't an issue. The only slow part of any of this is PBKDF2, unless you're dealing with huge files (not the case in chat).


Generate a public/private pair of keys for each user in each chat, using user-provided entropy (key strokes, etc.). For each message sent, encrypt it using a random single-use key and encode the passphrase using the recipient's public key. Recipient can decrypt the message after it decodes the passphrase using his private key


TripleSec seems to be only about the same person who did the encrypting, doing the decrypting -- for securing your own stuff, not really for communication. Communication requires exchanging keys beforehand...

[Edit: meant encrypting not encoding... thanks Perseids]


I may be a bit pedantic, but please don't use "encode" when you mean "encrypt". These words describe two quite different concepts and guarantees. Exchanging them the other way around produces catastrophic results like "Of course we encrypt our passwords, we use the renowned base64".


Agreed.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: