Session on LokiNet / Oxen - random thoughts

Read Session Whitepaper [2002.04609] from arxiv. First remark is that the mobile client doesn't support multiple identities. If privacy and security are preferred, then there should be separate identity for every contact, so there's no technical way to find out my shared contacts. Yet they acknowledge this problem in the documentation. It would be nice to have a client which would automatically solve this problem. If I'm in two groups A and B, user M who's also member of both groups shouldn't know that I'm the same user. That's very basic fail.
The documentation also nicely describes the challenges of encrypted group chats and related key management issues. As well as how challenging group chats can be in P2P networks, where the data is stored and how it's distributed. Open group solution using open group server isn't as good as I thought. I would have preferred falling back to channel encryption keys. Messages would be encrypted, but every member of the group would be using the same keys for encryption and decryption. The channel key could be also rotated at specific intervals, but not as often as closed channel keys which require huge mass of keying material, pairwise user to user encryption.
Multi-device sync and message delivery gets quite complex in P2P world, but that's nothing new.
Attachment handling is using onion layer, but centralized attachment server to store the encrypted content. Actually because such service is being run, this could have been used for the "open groups" but with encryption just as well, I think. Yet in this case it's possible to specify alternate attachment / file server to be used.
Chat app duress codes + remote deletion (wipe), nice features in some situations. I also like the pseudonym feature, yet having all the pseudonyms logged in simultaneously would be useful in some situations. Or choosing independent pseudonym for every contact / group automatically, if preferred. Actually this automatic pseudonym mode is that what I prefer. If someone is in two groups, why would anyone need to know it's the same user. Unless they want to personally reveal that.
Maximum message storage TTL is only 96 hours? That's good to know. Yet I assume the receiving client can request the messages from the source, when both are known to be online. Also this can be a risk, because messages are only locally marked as deleted. If someone gains access to the keys, the messages are still recoverable from the cloud storage (of course!).
One thing I like with Session it allows you to setup a session (hah), with only one public key and the key exchange happens automatically. Briar does require mutual public key swap before the session can be initiated. Of course if someone contacts you by your public key alone, you'll need to verify the contact. But it shouldn't itself be a complete technical showstopper. Sure, you'll also risk MITM in that case, unless the key contact verification in properly and thoughtfully completed.
MixMode is trying to mitigate risks of traffic analysis. Mixnet, decoy messages, loop back messages, cover traffic. I like that too, yet effectiveness of these measures need to be separately measured.
Message Layer Security (MLS) is nice rekeying optimization improvement. Also the Destination Privacy is essential, so the recipient information is hidden by using ephemeral tags for swarm routing as the reference, instead of using the users long-term public key.
Sorry intentionally no links in this post. Session is also interestingly lacking Wikipedia entry, oh well.
kw: service nodes, swarms, onion, identity, ephemeral, keys, private key recovery phrase, data storage redundancy, synchronous routing, asynchronous messaging using intermediate storage in swarm, deniable authentication, Signal protocol, Double Ratchet, encrypted group chat implementation and design, proof of work, loki name service (lns), traffic analysis, mixmode, Bitmessage, Mix Networks, surveillance, privacy invasion, briarapp, session messenger

2022-05-29