E2EE is fundamentally broken

[JavaDerg]

Hey, I'm too lazy to properly outline the issues I found, so I will just list them in a non-specific order, especially as the protocol effectively needs to be entirely redone anyway.

• Encrypting messages with RSA-OAEP which can only safely handle messages up to 245 bytes with 2048bit keys.
• • RSA in 2025.
• • RSA 2048bit keys, and not 4096.
• Extremely easy to MITM attack, the server can literally just swap out the received keys with their own.
• Files aren't encrypted at all.
• Leaks metadata everywhere, even when avoidable.
• No way to verify if the other party is who they claim to be / security numbers.
• Replay attack.
• AES key should be encrypted before exchange #378

Unsure if there is more, i genuinely only spend 15 minutes with the source code.

Here are some resources to maybe help you get a better protocol working.
Also look at the double ratchet as reference :)

• https://nostarch.com/serious-cryptography-2nd-edition (pdfs exist, but genuenly great book worth the money)
• https://soatok.blog/2020/06/10/how-to-learn-cryptography-as-a-programmer/

[muke1908]

@JavaDerg Thanks a lot for taking your time review and sharing important findings. Appreciate the learning materials I'll add them to the readme and create issues separately.

Unsure if there is more, i genuinely only spend 15 minutes with the source code.

I am sure there will be many more issues since it's a fun playground for learning and made by learner (including myself), but thank you again for your 15 min.

[ABHIRAM-CREATOR06]

Hey, I've been working on a side project (https://github.com/ABHIRAM-CREATOR06/Halonyx) that tackles exactly the issues mentioned here. It implements the Signal Protocol (X3DH + Double Ratchet) with X25519 and AES-256-GCM with no RSA anywhere.

I'm not sure how open the project is to a full crypto layer replacement, but if it would help, I'd be happy to contribute. Would love to hear @muke1908's thoughts before opening anything formal.

[muke1908]

@ABHIRAM-CREATOR06 Thanks! Sure, the encryption layer should be pluggable. Feel free to contribute.

[JavaDerg]

You could also possibly use smt like MLS which has many existing libraries that have seen propery reviews and assessments.

[muke1908]

Revisited this against the current master (service/src/crypto/). Status per original bullet:

Resolved / stale (no action needed here):

• RSA-OAEP / 245-byte limit / 2048-bit keys — no RSA usage remains anywhere in service/src; the default strategy is AES-256-GCM (crypto/strategies/secureStrategy.ts), keyed from a 256-bit invite secret that only ever travels in the URL fragment (crypto/inviteCrypto.ts), never through the server.
• Trivial MITM via server key-swap — largely addressed by the above: the server never sees the secret and can't substitute it. Residual gap tracked below (identity verification).
• Replay attacks — ReplayGuard (chat) and isStaleSignal/lastSignalSeqByCall (WebRTC signaling) both reject non-increasing/duplicate sequence numbers. I confirmed the signaling path was previously untested and added coverage for it in service/src/sdk.test.ts (dup seq, out-of-order seq, and per-call-id isolation).
• AES key should be encrypted before exchange #378 (AES key sent to server) — closed via fix: encrypt AES key with RSA before server exchange #434 (merged). Note: # fix(service): replace AES key transmission with ECDH X25519 key exchange #447 (open) targets an architecture (cryptoAES.ts, webrtc.ts) that predates the current invite-secret + pluggable-EncryptionStrategy design and no longer applies cleanly — flagging separately there.

Audited, no avoidable leaks found:

• Metadata — chatJoinPayloadType only carries channelID/userID (no userName), and the signaling/chat envelopes carry no extra plaintext beyond version/strategy/opaque data. Full metadata resistance (traffic timing/size correlation) isn't realistic for this project's transport model and is out of scope; nothing avoidable was found to trim right now.

Still genuinely open — tracked in new issues so each can be reviewed independently:

• No identity verification / safety numbers → #<SAFETY_NUMBER_ISSUE>
• No forward secrecy / ratcheting → #<RATCHET_ISSUE>

Deferred, not a #403 fix:

• File encryption — no file-sending feature exists yet; folded into User should be able to send file #320 as a requirement (commented there) rather than scheduled here.

Recommend closing this issue once the two follow-ups above are filed, since it's otherwise fully triaged.

[muke1908]

Filed the two follow-ups referenced above:

• Safety-number / fingerprint verification UI → Add safety-number / fingerprint verification UI #490
• Evaluate ratcheting for forward secrecy → Evaluate ratcheting for forward secrecy #489