The whitepaper at [1] is more impressive than I expected it to be, not for what is built today (which on a quick read appears to be rather unexciting), but for

The whitepaper at [1] is more impressive than I expected it to be, not for what is built today (which on a quick read appears to be rather unexciting), but for the class of attacks recognised as unsolved, and identified as requiring future work. Improvements identified include: 1) Encrypted messages should have a constant size (padded). Note that the Signal protocol used by Session currently uses variable length messages[2]. 2) Encrypted messages should be sent as noise by clients through the onion network and back to themselves at random intervals frequent enough that messages to/from other parties are statistically indistinguishable to an eavesdropper from the noise generated. 3) Intermediate nodes in the onion network should hold and delay encrypted messages so they are adequately mixed before being sent forward. This makes it statistically difficult for an eavesdropper to match up a message entering a node and a message leaving a node. Ideally messages would be mixed across enough nodes of the onion network that to an eavesdropper, the full list of possible destinations is equal to the total number of clients on the network. 4) Proof of work should be replaced with a better technique for preventing degradation of service or spam attacks. The paper quite rightly identifies that proof of work would favour Eve who has setup a data center filled with custom ASICs solving proof of work problems, rather than favouring Alice or Bob with an energy efficient mobile phone SoC. CAPTCHAs are identified as a possible future solution to this class of attacks. I doubt those improvements would have much application outside of labs and experiments though. Unless a significant part of the global economy surprisingly becomes dependent on a traffic analysis resistant anonymising protocol, it is too easy to just block such protocols similar to what China does with its Great Firewall. [1] https://arxiv.org/pdf/2002.04609.pdf https://arxiv.org/pdf/2002.04609.pdf [2] https://github.com/signalapp/libsignal-protocol-c/blob/master/src/protocol.c https://github.com/signalapp/libsignal-protocol-c/blob/maste...