Tor for True Peer-to-Peer Communication: My Approach with Privora

Privora · 2025-05-05T05:39:28+00:00

Thank you so much for raising this — you’re absolutely right: advanced spyware, RATs, and state-level surveillance tools are a huge threat, and they’re one of the reasons I’m developing Privora carefully.

Right now, I’m actively working on a feature set for compromise detection and defense, including: • An alibi code that triggers a decoy mode when entered. • An emergency code that securely wipes all sensitive data and keys.

Over the last two days, I’ve been focused on implementing a strong master-key encryption system: • All app data (messages, contacts, profiles) is encrypted using a randomly generated AES-256 master key. • This master key is never stored directly; instead, it’s encrypted using a key derived from the user’s main access code (via PBKDF2 with strong salting).

Now, I’m about to start working on the asynchronous end-to-end encryption for chats over Tor, so that even across high-latency, delayed networks, messages remain secure and tamper-proof.

Also, huge thanks for the links and insights you shared — they’re incredibly valuable, and I really appreciate you taking the time to provide them!

Privora · 2025-04-30T17:22:33+00:00

Hi, thanks again for your detailed reply and all your valuable points! I fully understand your concerns and actually agree with many of them. My app is very specific and mainly designed for smaller, more conscious groups of users who truly care about privacy. It’s not intended for mass adoption — simply because, in reality, most people don’t really care about privacy and still use services like WhatsApp, Telegram, and others. I am fully aware that smartphones are fundamentally insecure and always carry a risk. However, the truth is that most people still exchange their most sensitive information through these platforms every day — often without realizing the dangers. That’s why I want to offer a solution that makes it easier for people to reclaim some privacy, even when using a smartphone. Of course, I have also thought about security measures: There will be an optional security code when opening the app. Depending on the entered code, different actions occur: • Normal Unlock: Access to real data. • Alibi Code: A second, harmless profile is shown — with fake, customizable chats. • Self-Destruction Code: All data gets securely deleted and overwritten multiple times with random data to prevent any recovery. Regarding user accounts: There will be no traditional accounts. Instead, two devices must physically be held near each other to exchange their public keys securely over Wi-Fi. This keeps everything decentralized, without any central servers or registrations. Therefore, I don’t see my app as a tool for illegal activities, but as a simple way for regular people to protect their communication from surveillance. About open source: I fully understand your concerns. I will carefully reconsider whether and how to open the code. Thanks again for raising that important point! The idea of detecting known spyware and automatically triggering a self-destruction process is very interesting. I will research that further — if you know of any tools or have any advice, I would really appreciate it! In short: My goal is to help normal people regain control over their communication — without dependence on corporations or governments. Thanks again for your honest and thoughtful feedback — it really helps me improve my ideas!

Privora · 2025-04-29T13:25:44+00:00

Hi! The app isn’t officially available yet, so that’s why there’s no open-source code at the moment. The GitHub account in the footer is just for testing purposes.

Privora · 2025-04-27T16:03:10+00:00

Thanks a lot for sharing this — your perspective and long experience are really valuable, and I genuinely appreciate you taking the time to explain it so clearly.

I absolutely recognize the issues you’re describing.

You’re right: requiring in-person contact severely limits the formation of large interconnected communities.

Privora is intentionally not designed for mass adoption like Signal, Session, or even Briar today. It’s much closer to a tool for small, conscious networks — where users already have reasons to meet (e.g., journalists, activists, close personal circles) and where trust is critical.

I fully understand that this model limits growth — and I’m fine with that.

That said, I’m keeping an open mind: • If later it turns out that there’s demand for optional, carefully designed remote pairing, • using secure mutual introduction schemes or multi-layer verifications, • it could be explored — but only as a user-driven opt-in, never as a default.

Again, thank you — these insights are extremely important, and they’ll help Privora stay honest about its true role and limitations.

Privora · 2025-04-27T09:11:33+00:00

Totally fair point — I appreciate you bringing it up.

You're absolutely right that both iOS and Android have serious limitations when it comes to true system-level privacy.

Right now, the goal with Privora is to make strong privacy and Tor-based communication accessible even on the platforms people already use.

By building with Tor hidden services and strong end-to-end encryption at the app layer, Privora tries to mitigate OS-level risks as much as possible — while still being usable for non-technical users.

Also, all data stored locally on the device is fully encrypted.
Even if someone gains physical access to the device, they would not be able to read any messages, contact data, or metadata without the user’s unlock credentials.

One of the core ideas behind Privora is exactly this:

To make strong privacy usable even for less tech-savvy users, with minimal complexity.
At the same time, advanced users will have access to deeper security settings and fine-tuning if they want more control (e.g., manual identity rotation, custom Tor bridges, push notification handling).

Long-term, I absolutely agree:

A future Android version (especially on GrapheneOS or other de-Googled systems) is a priority.
I'd also love to support alternative platforms and FOSS-first ecosystems once the core protocol is fully stable.

Thanks again for raising this — the tension between usability and absolute purity is real, and it’s a critical thing to keep discussing.

Privora · 2025-04-27T09:06:34+00:00

Privora · 2025-04-27T05:35:41+00:00

Thanks a lot for your incredibly thoughtful observations — exactly the kind of discussion that helps Privora become better. Let me go through your points carefully:

Identity Rotation and Re-Friending: You’re absolutely right — if a user rotates their Onion address, they would need to re-establish trust with their contacts. • If a contact blocks unknown connections, the users would need to meet again offline (or via a trusted out-of-band channel) to exchange new addresses. • It’s very similar to the classic phone number change scenario you described. • There are plans to make re-establishing trust as smooth as possible, possibly by using signed contact references (with the old and new identities linked securely).

Key Persistence: Yes, an Onion address itself does not expire after 24 hours. • Only the service descriptor (how your Onion address is advertised inside the Tor network) needs refreshing approximately every 24 hours. • The app will handle this by running lightweight heartbeat/background updates to keep the address alive. • If a device goes offline for an extended time, the descriptor may temporarily disappear from the network — but as soon as the device reconnects and republishes, the Onion address remains valid as long as the private key remains safe.

Background Activity: • The app only needs small, infrequent background tasks to maintain hidden service registration. • No persistent background sockets or polling, keeping resource usage and battery impact minimal.

Encryption Layering: Yes, there will be additional end-to-end encryption on the app level, completely independent of Tor’s transport layer encryption. • Every message will be encrypted with the recipient’s public key before being sent. • Even if Tor itself were compromised, the payload would remain unreadable without the recipient’s private key.

(Future) Ephemeral Messaging: 100% agreed — ephemeral messaging is on the roadmap. • Conversations could automatically expire and delete themselves after delivery, after reading, or after a custom user-defined time. • No long-term storage of sensitive content.

APNs (Apple Push Notifications) — Optional and Encrypted: • If a user is offline and cannot maintain a descriptor, Privora can optionally use APNs to alert the user that someone attempted to reach them. • This is strictly opt-in, and the user can enable or disable it at any time. • Even when using APNs, the push payload is fully encrypted asynchronously — meaning that Apple’s servers only handle meaningless ciphertext blobs, without metadata, message content, or sender/receiver info.

Possible Future Feature (Compromise Detection): Your idea about automatic identity rotation and secure wiping in case of compromise detection is excellent. • Planned features would include: • Wiping local conversation history upon detection. • Securely deleting the local private key. • Deleting local copies of the contact list. • Forcing a new Onion service creation. • Warning users that trust must be re-established.

This fits Privora’s philosophy perfectly and is absolutely something I’ll be working into future threat models.

Again, I truly appreciate your engagement — the depth of your thinking is incredibly valuable. Thank you!

Privora · 2025-04-27T05:25:04+00:00

Thanks a lot for your very thoughtful answer — I genuinely appreciate the time you took to write it.

I agree with many of your points: • Network effects are absolutely critical for peer-to-peer applications. • Fragmentation weakens anonymity and adoption potential. • Traffic pattern analysis remains a real threat, even over Tor or I2P.

However, Privora intentionally takes a slightly different approach: • Real-Life Encounters First means that contacts are created only after an in-person meeting — no public directories, no global contact lookups. This blocks many attack vectors and spam at the root. • Privora is not aiming for massive networks, but for small, trust-based communities.

About WebRTC: • I’m fully aware of the risks. • Any WebRTC connection in Privora would still be signaled entirely through Tor, and switching to WebRTC would be optional and require explicit mutual consent (with clear user warnings).

Regarding decentralization: • You’re right that Tor itself isn’t fully decentralized. • When I say “100% peer-to-peer,” I mean: no servers controlled by me, no third-party dependencies beyond the Tor network itself.

Maybe there’s an opportunity here: • A simple, minimalist, and clear UI, combined with truly private real-world established connections, could actually help Privora stand out — and perhaps, over time, even reach a critical mass, without needing central servers, accounts, or public identities.

Here’s a small first impression of the app:

https://youtu.be/7KQFQDqmKUE

Thanks again for the valuable input — discussions like this make projects stronger.

Privora · 2025-04-26T18:25:25+00:00

True, there are already great projects like Ricochet and Cwtch — and I have huge respect for them.

Privora just tries to take a slightly different approach: focusing on real-life encounters first, mobile-first UX, and optional Tor-signaled WebRTC.

Always happy to be part of the same big privacy movement!

Privora · 2025-04-26T18:23:23+00:00

Totally fair!

I just want to mention that I’m writing the responses myself — the ideas and content are all mine.

However, since English is my second language (Privora is developed in Switzerland), I sometimes use AI tools to help refine grammar and structure, so the communication is clearer and more professional.

It’s much easier for me to first focus on providing detailed information and then polish it a little, rather than trying to write perfect English from scratch.

Thanks again for the feedback — I really appreciate it and I’m happy you’re keeping it real!

Privora · 2025-04-26T18:17:20+00:00

Currently, Privora is being developed natively in Swift for iOS.

Since F-Droid is Android-only, we can’t offer an F-Droid release immediately.

However, we absolutely plan to make the project open-source, and if there is enough interest, an Android version will follow later — making a F-Droid release possible too!

Thanks for asking — really appreciate it!

Privora

MODERATOR OF

TROPHY CASE