3 ms·
From FAQ: Q: Can I backup my messages? A: No. :( The killer feature set of a messaging system that will allow it to crush WhatsApp, Signal, Session, etc: * Fu
by permille42 6y ago
From FAQ: Q: Can I backup my messages? A: No. :(
The killer feature set of a messaging system that will allow it to crush WhatsApp, Signal, Session, etc:
* Fully open source ( app, nodes, everything )
* End-to-end encryption ( obviously )
* Rotating keys for deniability. Basically just create time valid subkeys and periodically post the private key to the subkeys. Probably once a day would be sufficient.
* Full message export/import including tweaking and faking messages. It isn't really deniable if you can't show you could easily fake some past messages.
* Fully capable Linux client, so that we aren't forced to use an untrusted and possibly backdoored phone to use it.
* Extra secure time bucketed send/receive if you want to avoid timing attacks on location.
* Hash section bucketed messages along with the bucket by time. For example, if your public key is 4BC56..., you can request all messages sent to 4BC* and get them all, so it isn't then obvious who exactly you are.
* Subkey unique per communication partner. This way gaining someones subkey for a time period doesn't let you potentially capture other packets you know are encrypted and decrypt them too...
* URL based identity. Post your public key to URL; tada that URL can then be used as your identity. Have a bunch of different secure countries host free identity upload sites.
* Group chat which just makes it so you communicate every message to every other partner in the group chat and vice versa. Any other way wouldn't be secure.
* Message size padding to private size based packet matching.
* Automatic sending of periodic messages to bogus destinations. This way it is not immediately apparent if you are sending something out or not. Preferably this would include adding random people and engaging in nonsense chat sessions with them for random amounts of time. Only the client on the other end would know if it is a bogus message or not.
* Message nodes completely wipe all data hourly ( for regular messages ) or daily ( for the daily grouped messages )
* Message nodes all ban any client attempting to download more than a certain threshhold of data. Publish the banned clients publicly. Expose the watchers.
* No registration. Basically anyone should be able to send/receive through whichever node they wish that has available bandwidth. You send an encrypted chunk with a destination ID. Others can download chunks tagged with some hash part of the destination.
* Central "saturation tracking node" that receives saturation from all registered nodes in the system and just publishes a file on a URL for whoever wants it to figure out which node they will use to communicate that isn't over-saturated.
* Can post a set of nodes you listen on to your URL with public key periodically so clients know how to start communication with you. Once established; switch to unsaturated nodes...
The following features are somewhat irrelevant:
* Onion routing. Just connect to the service through any number of other onion routing systems. No need to put all our eggs in one basket. Use a private VPN + Tor to connect to the system. Done.
- loup-vaillant 6y ago> Rotating keys for deniability. That's only needed if you sign with those keys. DKIM for instance. If your protocol is based on key exchanges (as Signal is), you don't really need to rotate anything, because recipients can always fake messages coming to them. (Group discussions however may be another matter.) That said, there are other reasons to rotate keys, typically to diminish the probability and the impact of leaks.