Session Encrypted Messenger

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • session-desktop

    Session Desktop - Onion routing based messenger

  • session-android

    A private messenger for Android.

    > reproducible build available at F-Droid

    It's not available at F-Droid. They have an F-Droid compatible repository that you can manually add to your F-Droid client where they ship binaries.

    I also can't find any mention of reproducible builds on their website, and their builts seem to include proprietary binaries.

    The issue [0] to publish the app on F-Droid is still open.

    0: https://github.com/oxen-io/session-android/issues/73

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • wire-server

    🇪🇺 Wire back-end services

    > See also Wire who had serious crypto and promises to open source everything, but to my knowledge the server side was never released

    The wire server code is open source AFAIK [0]

    > This repository contains the source code for the Wire server. It contains all libraries and services necessary to run Wire.

    [0] https://github.com/wireapp/wire-server

  • libsignal-protocol-c

    Discontinued Signal Protocol C Library

    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 Eve 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 Eve 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

    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

    [2] https://github.com/signalapp/libsignal-protocol-c/blob/maste...

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts