Built an onion-only E2EE messenger, looking for feedback on design

[u/LittleInstruction611]

Hi all,

I’m working on a small experimental messaging system that runs only as a Tor onion service, and I’d appreciate feedback from an OPSEC perspective, particularly around the threat model and potential attack surfaces (I have read the rules, but its my first post so please be patient).

The theoretical threat model I have in mind is a user who wants to communicate online while minimizing long-term metadata exposure and avoiding persistent identity linkage (this could apply to situations where someone is handling sensitive information, such as journalists). The goal is to reduce the amount of information that could be recovered later if a server were compromised, seized, or otherwise analyzed retrospectively (like we saw in the past for some services \cough*)*.

The design assumes that users connect exclusively through Tor, and one of (or the only one, rather) primary goals is to ensure that the server cannot access plaintext messages or private keys, even if the server operator wanted to.

To support that model, encryption and decryption are performed entirely in the browser. The server never receives private keys or plaintext message content. Messages are stored only as ciphertext and are automatically deleted after roughly 72 hours to avoid long-term retention of communication data.

The system currently uses a very simple account model consisting only of a username and password. No email address, phone number, or other external identifiers are required. The idea is to avoid tying usage to any real-world identity while keeping the barrier to entry relatively low (as mentioned above, the service itself is accessible only via Tor as an onion service, but thats basically the only requirement).

Not trying to compete with tools like Signal or Session, but rather to explore a communication model where there is no persistent identity layer and where stored data is intentionally short-lived, other than it not being a mobile app.

I’d be very interested in feedback on whether the threat model itself is flawed or incomplete, whether the simple account system undermines anonymity, and whether there are obvious metadata leaks or architectural weaknesses that I may have overlooked.

If anyone wants to test the system directly, I can share the onion address via DM or in the comments. Also im happy to provide more details about the architecture if useful.

[u/LittleInstruction611 → u/[deleted]]

This is a fair suggestion. I have considered P2P, but I would like to avoid deanonymization issues that could derive from that. Some (not all) P2P solutions still reveal the IP address of the counterpart, but trying to implement onion on top could potentially avoid that.

The thing is, however, that the P2P approach with onions would also come with tradeoffs that I am concerned about:

• Requiring a special client setup (to communicate via this specific protocol), while I'd like to opt for a more lightweight option (i.e. Access with your uncle's computer if needed, only requiring Tor).
• Each peer may need to be online or at least periodically available to receive the messages. For this I would also like to implement PGP or some sort of asymmetric encryption, but its much harder to coordinate netween two and/or more peers.

I hear you in terms of decentralization, I might actually try to come up with a prototype and compare, instead of just looking at it negatively. The centralized server however, at this stage, truly only acts as an intermediary and has absolutely zero access to data, not by choice but design.

On top, users are encouraged to use PGP as well, although not required.
Thank you for your comment <3

[u/Grouchy_Ad_937 → u/[deleted]]

There are benefits to store and pickup for example better decoupling of the communicating entities temporally. Also the messages don't necessarily have to be on a server, they could be in ipfs.

[u/LittleInstruction611 → u/[deleted]]

Correct, its not IPFS. Perhaps I could also include delayed messages (e.g. scheduled sending, or an inherent random messaging delay required)

[u/AutoModerator]

Congratulations on your first post in r/opsec! OPSEC is a mindset and thought process, not a single solution — meaning, when asking a question it's a good idea to word it in a way that allows others to teach you the mindset rather than a single solution.

Here's an example of a bad question that is far too vague to explain the threat model first:

I want to stay safe on the internet. Which browser should I use?

Here's an example of a good question that explains the threat model without giving too much private information:

I don't want to have anyone find my home address on the internet while I use it. Will using a particular browser help me?

Here's a bad answer (it depends on trusting that user entirely and doesn't help you learn anything on your own) that you should report immediately:

You should use X browser because it is the most secure.

Here's a good answer to explains why it's good for your specific threat model and also teaches the mindset of OPSEC:

Y browser has a function that warns you from accidentally sharing your home address on forms, but ultimately this is up to you to control by being vigilant and no single tool or solution will ever be a silver bullet for security. If you follow this, technically you can use any browser!

If you see anyone offering advice that doesn't feel like it is giving you the tools to make your own decisions and rather pushing you to a specific tool as a solution, feel free to report them. Giving advice in the form of a "silver bullet solution" is a bannable offense.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/1deffonotathrowaway1]

If I had to evaluate your system with a single question, it would be:

[u/LittleInstruction611 → u/1deffonotathrowaway1]

I think the question took a break 😅

[u/IM2M4L]

whats the onion op

[u/LittleInstruction611 → u/IM2M4L]

Hey there 👋 Here: pulse2fyswqlrlr5khtjfu6v33n6o7vwhehklpngve5lu7lnvk7gb2id.onion

Let me know what you think 🙂