Sweet Lies

From Dan Shearer CV
Revision as of 16:52, 25 August 2022 by Dan (talk | contribs) (Clarify)

The Sweet Lies project aims to make the respected Signal secure chat app and chat server available to everyone.

Privacy is closely related to fundamental human rights. In the case of private communications, the personal safety of individuals is often at stake, and private chat gives vulnerable people and groups some degree of protection. In the 21st century private communications is about mathematics used in software apps, and whether or not those apps have had the mathematics compromised so that someone can listen in on all messages sent. A vulnerable person trusting a chat app is more vulnerable if someone is able to secretly listen to everything said, and that can lead to tragic outcomes. While it is obvious that warzones and domestic violence put individuals at risk, anyone can become vulnerable at any time.

The Signal secure chat app is the best existing solution for private communication, and the Signal team are quite rightly respected around the world. Signal consists of an app available in appstores, and a Signal Server app run on a group of large computers in one particular Amazon datacentre. The software for Signal is open source. If you are using Signal, you are likely secure against some of the most common ways that someone would use to listen to what you say. But due to certain issues of transparency, there is a lot more that could be done.

The Sweet Lies project changes the Signal Server code to make it possible to run your own Signal server anywhere you want.

NLnet has awarded funding to Sweet Lies.


Fluister.png

Why Signal is Really Good

Signal is the only personal messaging codebase which has good privacy and is all of:

✅ Validated by independent, academic, cybersecurity peer review

✅ Open Source

✅ Widely used, clients on multiple platforms, reasonably accessible clients

✅ Mainstream - many tens of millions of users. Even the EU parliament insists on Signal for internal communications

✅ Seemingly, so far, resistant to efforts of criminals and also government authorities to break its most detailed security

✅ Full of features. Signal can be compared to other mainstream apps like WhatsApp and Telegram. Signal does not require special or geeky knowledge to take advantage of its extra-good security

What Is Not So Good About Signal

Signal also has some urgent problems:

❌ Signal is not reproducible. Reproducibility is a first basic requirement for security and therefore trust. This is a not a deliberate ploy on the part of the Signal team, they are simply very busy making a good app.

❌ Nobody can deploy a Signal server themselves (calling it something other than "Signal", of course).

❌ Inspection of the Signal server code shows that it uses six US-based closed source cloud services. These US services are an opportunity for sidechannel attacks and traffic analysis. Signal is still the most secure messaging system: it is end-to-end and does not store user data except to forward when necessary.

❌ Signal no longer enables federation of user data, meaning interoperability is not testable and that the servers run by Signal Messaging LLC are a single point of failure. Denying access to secure messaging is one way of attacking vulnerable people.

❌ Signal is not legal or even suitable to use for communications in Europe, because of the US cloud dependencies and also because of the lack of reproducibility. Something as vital as Signal (recommended for use by the EU parliament!) needs to fully comply with EU privacy regulations, for the benefit of all users everywhere.

❌ Signal is currently entirely hosted in the US, in an Amazon datacentre. This is legally and technically unacceptable for EU organisations given the above potential vulnerabilities.

❌ Signal Server is configured to give some security information about individual end users to Content Delivery Networks without disclosure or consent.

Introducing Sweet Lies

The Sweet Lies goal is to create a reproducible build of Signal client and server code, and then uses this to set up a Signal network. The outcomes will be a recipe for creating a Signal-identical network, with evidence that this recipe gives correct results. The next stage is to enable federation for connecting to other, independent Signal server instances, but since federation in Signal has been deprecated since 2016 there are many unknowns.

Sweet Lies relies on the production Not Forking tool developed for LumoSQL.

It seems very likely that when we can turn on a clone Signal network, that organisations of all kinds would very much like to have that same system themselves so they can be assured they have their own private Signal. This is a commercial opportunity.

(Why the name "Sweet Lies"? Several other names proved unusable, and the Fleetwood Mac song is about keeping secrets safe!)

Sweet Lies FAQ

Signal is an old design. Why not just write a modern distributed chat system? Because that will take years to build and have verified, and people need secure chat now, sometimes for life-and-death reasons. In 5-10 years probably nobody will be using Signal, but today there really isn't a choice.

How long will this take? It is now the end of February 2022, and I estimate the first test builds will be available by around the beginning of July 2022, with publicly visible progress well before that. There are a lot of details to figure out.

If Signal has all these problems, why not do a hard fork and fix them? Because the Signal team are doing a really good job, and I would not want to try to duplicate what they do without having a large team with plenty of funding. Especially if it was just to try to replicate all the best parts of Signal which we could have for free already!

What about Matrix? They are open source and they just got lots of funding! The Matrix team are lovely and I wish them every success, and they do produce quite a functional federated chat solution. I have personally found Matrix to be unstable at even quite modest scale. In my view Matrix has a very large codebase for the functionality it delivers, and it would probably be very difficult to conduct an independent security audit of the Matrix code. A lot of projects would love to use Matrix instead of, say, libera.chat - but they can't because Matrix still has these limitations. I'm very open to hear updates and corrections on this. Is someone independent studying the attack surface of Matrix? Are there new developments that make Matrix more stable at scale?