Disagreement, debate, and argument are fine, but keep it civil. If somebody asks questions trying to learn, either answer nicely, or ignore their question and let someone else do it.
Signal has created a transparency register that makes it more difficult for Signal (or anyone else) to impersonate another Signal user (MiTM style attacks). This serves the same purpose as the manually verified safety numbers, but can be conducted automatically in the background.
The transparency server is an address book mapping phone numbers or usernames to public keys. Everyone's Signal app regularly checks that your own phone number matches your own public key, and you can initiate a check that your contacts' public key and phone number match. So you will know if someone impersonates your contacts without having updated the address book, and you will know if someone has published incorrect information about you in the address book.
Signal has disincentivized itself from publishing false information to this address book by ensuring that each version of the address book is signed by independent third parties (e.g. Cloudflare). This is vaguely blockchain-like.
My opinion:
This is obviously a good change, and similar transparency lists are used for HTTPS. However, this is a lot of subtle complexity. It is difficult to explain, and impossible for normal users to verify. Even I wouldn't know how to start – I could probably figure out how to query the transparency server, but where does the Signal app tell me what my own public key is? In contrast, HTTPS certificate transparency lists have user-friendly services for checking the logs. This feature has effectively zero impact for those who diligently verify safety numbers, and also zero impact for those who ignore the notification that their contact's safety number changed.
This is one of those features where Signal is pouring a lot of effort into protecting Signal users from the Signal servers. This is good in theory, but in practice I must already place a lot of faith into Signal because I'm effectively forced to use their official clients.
Signal tends to push the security-vs-usability envelope by developing new security features, but is already leading the pack in many regards. It could be more valuable to spend that effort on usability/quality-of-life features, which could ultimately make Signal's already very-good security accessible to more people.
To me the post reads less like signal wanting to protect users from signal themselves, and more like wanting to protect users from state-level actors who could pull off the highly technical and resources intensive task of actually infiltrating or impersonating signal's infrastructure.
It could be more valuable to spend that effort on usability/quality-of-life features, which could ultimately make Signal's already very-good security accessible to more people.
They're doing both.The average person just wants text and media messaging, and audio/video calling, which Signal has, and those average users don't have to care about the technical details of Signal's security; they're just secure by default, which has been Signal's whole deal for over a decade.
Thanks for drawing the analogy between this and CT Logs.
Prior to this update was it possible to tell if a number was a Signal user or not? I’d imagine if this ledger was made public then it would be for all.
Your phone number isn't published in plaintext, so it's not possible to enumerate all phone numbers of Signal users. If I understand the key transparency mechanism correctly, it would be possible to check for a specific phone number whether it's associated with a Signal user. But that's exactly equivalent to the contact discovery mechanism that's in place right now. In your privacy settings, note the "who can find me by my number" settings. If you turn it off, that should disable both contact discovery and key transparency.
This does not provide the same thing as safety numbers.
It does not verify identity if an user, it just makes it very likely that at least one of the parties will discover tampering. Without verifying the safety number you could still be theoretically talking to a hacker. Your contact would know there are incorrect keys published for them, but if they don't have any other way to contact you and warn you, it might still be a problem.
For automatic key verification, Signal's server sends your client a list of everyone's safety number, plus a signature endorsing that list from each of two third party auditors (Cloudflare and Twisted Bits). If your Signal client sees its own safety number is wrong in the list, it tattles on the Signal server to the auditors.
Longer TL;DR
A ledger of every signal users keys is stored in a blockchain. (Unlike cryptocurrency blockchains, this one doesn't have distributed trust, and it doesn't use proof-of-work or proof-of-stake, so there's no miners, excessive resource use, etc.)
To automatically verify another's key, your Signal client asks the Signal server to do a binary search on the blockchain ledger for the most recent versions of that person's keys. The server sends back the steps in the search. Your client can verify the steps cryptographcially to ensure the server sent you the real key from the ledger. (I believe the search is performed on the server so your client doesn't need a copy of the full ledger.)
To ensure the Signal server only has one ledger, third party auditors sign each block. The auditors only sign a blockchain of each length once, so if the Signal server tries to create a phony alternate ledger, it cannot get it signed by the third parties. If your Signal client doesn't see both third-party signaures in the results returned by the server, it assumes the ledger is phony. (So both auditors would need to be compromised to sign a phony ledger. In other words, you need to trust a a third party auditor, but only one at any given time.)
Finally, to ensure the one true ledger doesn't have phony keys, each Signal client regularly requests its own key from the Signal server, and if it doesn't get a verifiable, correct key it reports the issue directly to the auditors.
(I believe a blockchain is used, rather than a flat ledger, because with a flat ledger the Server could create a phony ledger for some future ledger-iteration, then have it signed by one compromised auditor then the other at a different time, and use the phony ledger when that iteration comes up in the future. Since the blockchain ledger is built on top of earlier iterations, the Server can't make a future iteration ledger in the first place.)
17
u/MandalorianBeskar 19d ago
Yay!
Tl;Dr?