The problem it’s trying to solve is mostly straightforward. I’ll provide a high-level overview so as to not complicate things (a lot of this is simplified):
When you create an account on signal, you create a private key and a public key. When you DM someone, you’re communicating with your public keys (simplified). Your private keys remain with you. However, this creates a very big problem that’s not new to signal, but has existed since TLS (previously SSL):
If you are trying to communicate with Bob over the internet, he’s supposed to give you his public key over the internet.
But, how do you know that the person who replies to you with their public key is actually Bob? What if someone else gives you their public key and says they’re Bob? The easiest way would be to physically meet Bob, and check whether the public key you received over the internet matches. However, this is impractical (live in different countries?).
TLS solved this with certificates. How do you know that the byte stream of data you’re receiving from lemmy.world is really coming from Lemmy.world, and not malicious-lemmy.world? Because of certificates: someone you trust cryptographically said that the byte stream is really from lemmy.world. Your device with which you use to access the internet (phone, laptop, browser) comes with pre-installed certificates. Here’s the list Mozilla ships with Firefox: https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootCertificateReport
Solving this with signal isn’t that easy. There’s problems (users may change numbers / usernames), and general certification is… just not that simple. That’s why, when you DM someone on signal, you can “mark safety number as verified” if you can verify that you both see the same number (you do this over a medium that isn’t signal).
Signal is now introducing a solution called Key transparency (defined by the IETF: https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/), which in essence says that your device periodically checks your own entry on a ledger that signal now hosts, and you can initiate a check of your contact’s entry too.
If you notice your key on the ledger is wrong, something bad happened (malicious). If the other person’s key on the ledger changed, then you should verify that it was indeed meant to change (new phone? New number? New username?). Because the server that provides the ledger could theoretically show different people different versions of the ledger, independent auditors attest the ledger, making conflicting views detectable (you might pull the wrong ledger from a malicious person, or signal may give you wrong ledgers maliciously). They’re entrusting external parties to attest that the data that both parties of a DM get the correct view of the ledger.
This is what I understood after a cursory reading, and I may be wrong. It is also simplified. But I hope that this is mostly correct.
It’s solving a very old problem of public-key cryptography: how do you ensure that the person who is talking to you claims who they are? Are you sure you’re really talking to Bob, and instead not Mallory who’s pretending to be Bob?
Tagging @k0e3@lemmy.ca too.
Hi! I just wanted to say thank you very much for making BentoPDF - I’m a big fan! It’s a tool I use regularly and I’m always very happy that it’s so intuitive and easy to use. I learnt about it from lemmy here (your post 8 months ago), btw!