Signal's Meredith Whittaker on the Telegram security clash
techcrunch.com
techcrunch.com
The signal protocols are well documented (https://signal.org/docs/). But their code and architecture? I'm not aware of any docs in that regard. For example, an overview of the code structure is missing. If I wanted to know how the database is encrypted in their apps, do I find an overview on that? Where is the architecture documented? Are the design choices documented anywhere?
You might say, "read the source". I did that a few times for certain parts of the code (in their Android app), and it has very few in-code comments.
Now of course it's perfectly fine for Signal to publish their code this way. People with the specific developer experience will still be able to find the code they're looking for after some searching. But the claim "the code is well documented" seems like quite a stretch to me. I'm pretty sure such docs do exists somewhere, otherwise onboarding new developers would be quite hard. But they're probably not published?
(If there _are_ public code docs, links would be appreciated.)
Inside of the database the text is readable as plain text, unlike for example Bitwarden where the database itself is not encrypted but individual fields are.
Another example: For years the database for the desktop app was unencrypted, because "you can just use FDE" (according to GitHub commenes). Last time I checked, they switched to SqlCipher as well, but with the password in an unencrypted file right next to the database file.
What's the threat model of such an odd design choice? Are there any docs on that?
Don't lose your device while it has data on it or hope the OS has good enough security to stand up to an adversary with local access to the device. The sql encryption on the database is mostly useful for backups which wouldn't send the key along with it.
If they document it, it becomes a standard and people start to rely on it. Even if the documentation itself is merely to explain the how and why of the database's encryption.
> Last time I checked, they switched to SqlCipher as well, but with the password in an unencrypted file right next to the database file.
> What's the threat model of such an odd design choice?
The only thing that is more secure is to use Window's Credential Manager to store the key, which is what Bitwarden does [0].
But those credentials can also be easily dumped [1]. But at least this means that a system-wide data dump doesn't reveal the DB's content.
I am not well-versed in the credential manager, but I wonder if it is possible to tie the credential to the executable (signer? hash?).
[0] https://github.com/bitwarden/clients/blob/89d7e96b25594e51a7...
[1] https://gist.github.com/micjabbour/654e67d29cbd62be3587b9f1d...
Easy and not odd at all, I would say: if your computer/smartphone is compromised, you're screwed. If an external program can read what appears on the screen, then no matter what kind of encryption you have at rest, they will be able to read the text.
So if it matters to you, you should make sure that your device is not compromised; it cannot be done by Signal. What Signal can guarantee, though, is that it can transmit messages securely between non-compromised devices. And that it does well.
They use sqlcipher (sqlite with encryption extensions) and did not roll their own encryption for this. If an adversary is able to unlock and decrypt the device (like has physical possession of it) they will have access to all messages stored on the device. Docs here: https://www.zetetic.net/sqlcipher/design/
- if you use iOS, and actually use signal (with history on and everything) transferring to a new phone is a multi-hour amount of work and is not trivial. You need to 1) turn off auto lock, which you may not be able to thanks to MDM. 2) scan QR code and wait hours for data transfer (dependent on your history size).
This means that if you brick your device, trade it in, or whatever, you can’t actually restore your chat history. This entire model is unnecessary and there’s plenty of ways to improve this.
- on Linux devices, and possible more (not an issue on macOS) the chat history is stored in a flat file owned by your user. I’m not going to sit here and say the keyring provided by your DE/WM is great, but it should still be used here. Mainly because as those keyrings improve, the rising tide improves everything else. As it stands today, literally any application running as user level permissions can read your signal encryption keys. You don’t even really have a way to rotate those keys.
Signal, please. I want to like you. Please focus on usability and actual security instead of the constant hit pieces against telegram. It just looks petty. It also looks like you’re angry that telegram’s crypto is actively taking off while yours failed.
No offense, but to me it sounds like Whittaker complains about the bad encryption in transit (i.e. "the Telegram server can read your messages") and your answer is "that's FUD, because exporting on iOS is annoying and if your Linux is compromised, then your Linux is compromised"?
I mean sure, you can like Telegram better because you love stickers and whatnot, but how can you call that "actual security"?
> The focus on deepfakes in a vacuum is actually missing the forest for the trees, with the ‘forest’ being the fact that we now rely on five massive social media platforms as the arbiters.
I think the way legislators have come to understand media - at least by the way laws are being written - is that the collection, distribution, and filtering must happen on a single platform. So there's this attempt to force platforms to be the arbiters of truth.
But this is dangerous in several different ways:
1. It is impossible to be an arbiter of truth, it's a fundamental problem of epistemology that cannot be solved without perfect knowledge of the "real world", and so the platforms must necessarily be allowed to fail to some, or a large degree.
2. Having been given this impossible responsibility, the platforms are going to disallow/punish based on controversy, because their real problem isn't breaking the law, it's others bringing attention to where they're breaking the law.
3. In the meantime the platforms might offer some token resistance to these laws, but ultimately they will not say no to being handed the one tool that gives them enormous political and economic power, power which will protect them if the law comes after them.
These three points will keep reinforcing themselves to lock us into the information dystopia we're in today.
I don't think it's possible to preserve 1. freedom of speech, 2. protection from mis/disinformation unless the different layers could be forcibly separated. My current crackpot idea is that the distribution and filtering layers have to be broken up in a way that both forces information to flow freely, and allow consumers to protect themselves by consciously selecting and filtering their consumption in meaningful ways. Filtering providers cannot be given the power to control information supply for other filtering providers, which allows the market to abandon untrustworthy providers at will, and also gives the authorities the degree of power required to find bad actors and dispense meaningful punishments.