3 ms·
TLDR: Everyone seems to be assuming that there's a single point of failure, and someone gets to see all the information. I would definitely not build the thing
by kilburn 7y ago
TLDR: Everyone seems to be assuming that there's a single point of failure, and someone gets to see all the information. I would definitely not build the thing like that if I was the one doing it.
There's not much information about how the application works. What we know is:
- The app seems to use a RetroShare network behind-the-scenes [1].
- RetroShare is a decentralized, serverless, peer-to-peer, meshed, distributed network. When you join you generate a pgp key for yourself and then add "friends" by grabbing their public keys.
- The app needs to be activated through a QR generated from another person's app who's already in.
- The app monitors your location and only shows you close-by actions.
What I would like to confirm:
- Whether the QR is the same for everyone, the same for every person sharing it, or generated on a by-share basis
- Whether RetroShare is actually used or not.
Assumptions I make:
- There's a non-trivial organization behind this
- The organizers do not want to be discovered, and want to have as much "plausible deniability" as possible (they are risking jail time)
Given all the above, here's how I would build this application:
- Create 3 (or 5) "root" keys. The very top people in the org get those.
- When you join the network (by scanning someone's QR), you join the RetroShare network, but also get the root keys id's.
- The app is now ready to handle some message types from the root keys:
1. STOP. Accepted when signed by any of the active root keys. The app stops sending messages.
2. ADD_ZONE. Accepted when signed by a majority of the root keys. Adds a new zone (a geographical bounding box) along with the public key of the zone's commander (someone who can organize stuff in that area).
3. REMOVE_ZONE. Accepted when signed by at least two root keys. Removes a zone because it either has no activity or has been compromised.
- During normal operation, the app tracks the currently active zones and the corresponding zone-masters. It monitors your location, and if you are within a zone it sends "in-zone" notifications to the zone-master.
- The zone-master collects such notifications and sends direct messages to people in their zone when an action is to take place.
As I see it, this would be the simplest setup to accomplish the organizations' goals without much possibility for compromise. As soon as a zone is compromized it can be nuked, and the whole thing can be nuked quickly if some root is compromised too.
You could then start refining this basic idea with extra functionalities. For instance:
- Add/remove root keys to avoid having to nuke everything if a root gets compromised.
- Get the app to send "in-zone" messages to random zones from time to time and then filter received actions according to actual location. This would prevent the organizers (or someone who gets to observe the traffic) from inferring the users' real location.
[1] https://retroshare.cc/ https://retroshare.cc/