It seems encrypted messengers are turning into cryptocurrency ponzi scam projects.<p>Keybase -> Stellar<p>Session -> Oxen/Loki<p>Whatsapp -> Diem/Novi<p>Signal -> Mobilecoin [0]<p>There really is no defence of introducing this at all and it's sad that this is becoming a trend, looks like one has to look at Threema, Wire and possibly Element as our only hope.<p>[0] <a href="https://www.wired.com/story/signal-mobilecoin-payments-messaging-cryptocurrency/" rel="nofollow">https://www.wired.com/story/signal-mobilecoin-payments-messa...</a>
I've looked into this before a little. But no one seems concerned these guys are located in Australia. We (Australia) have what I'd call quite frankly, "Awful" encryption and privacy laws.<p>edit: they touch on it here: <a href="https://getsession.org/blog/on-the-recent-australian-surveillance-legislation" rel="nofollow">https://getsession.org/blog/on-the-recent-australian-surveil...</a><p>But AFAIK with the news laws nothing is stopping the feds from requesting them to upload a backdoored apk one of these days (if someone can shed more clarity on that, I'd be appreciative).
Even though the website looks like yet another "secure messenger scam", at least these guys check the important checkbox of having a reproducible build available at F-Droid. [or apparently not, see below for more]<p>This check box is actually quite import; I laugh at anyone who promises that "they won't reveal identities, not even under a court order" when the court can just force them to ship a silent binary update that does whatever the heck the court wants.
It is linked to a cryptocurrency called Loki.<p><a href="https://crypto.com/price/loki" rel="nofollow">https://crypto.com/price/loki</a>
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.<p>Improvements identified include:<p>1) Encrypted messages should have a constant size (padded). Note that the Signal protocol used by Session currently uses variable length messages[2].<p>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.<p>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.<p>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.<p>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.<p>[1] <a href="https://arxiv.org/pdf/2002.04609.pdf" rel="nofollow">https://arxiv.org/pdf/2002.04609.pdf</a><p>[2] <a href="https://github.com/signalapp/libsignal-protocol-c/blob/master/src/protocol.c" rel="nofollow">https://github.com/signalapp/libsignal-protocol-c/blob/maste...</a>
There are so many encrypted messaging apps now but none has the feature-parity and convenience of Telegram. The user experience is just unparallel, and it is quite astonishing to see so high-quality software being produced by an actual company these days. However, there are a couple of drawbacks of Telegram which are seriously important to consider<p>- no self-hostable server option (of course they don't have a federated model so interoperability will not be easy even if they release the server source).<p>- the encryption protocol is non-standard, does not sync between devices, and is not enabled by default.<p>I would really love it if there is a client-side encryption app which uses established time-tested encryption protocol to encrypt and decrypt messages fully at client side and will just let me use something heavily feature-rich like Telegram for sending the messages.
Session is a cool fork from Signal. They adress the two biggest privacy issues, push tokens and IP addresses.<p>But I can't see it gaining too much main stream traction any time soon. Too me it feels like WhatsApp has hit the sweet spot for people who can't get themselfes to care about security and privacy.
Looks good but it is centralised if I understand correctly. Same weakness as Signal or Threeema. Element [Matrix] should be prefered for decentralisation.
A good implementation in secure messaging app that doesn't use meta data at all, ( only a pubkey ) is olvid.
<a href="https://www.olvid.io/assets/documents/2020-12-15_Olvid-specifications.pdf" rel="nofollow">https://www.olvid.io/assets/documents/2020-12-15_Olvid-speci...</a>
The company/main developer seems to have ties to the alt-right
<a href="https://nitter.42l.fr/WPalant/status/1281540005190672384" rel="nofollow">https://nitter.42l.fr/WPalant/status/1281540005190672384</a>