3 ms·

"Our protocol is open source. Our code is open source. It’s well documented. Our implementations are open source. Our protocol is formally verified. We’re doing

"Our protocol is open source. Our code is open source. It’s well documented. Our implementations are open source. Our protocol is formally verified. We’re doing everything we can." The signal protocols are well documented (https://signal.org/docs/ 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.)

OptionOfT 2y ago
FYI, last time I checked Signal's sqlite database was encrypted with SQLCipher [0] 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. [0] https://github.com/sqlcipher/sqlcipher https://github.com/sqlcipher/sqlcipher
- melgafin 2y ago
  Yeah, but are there any official docs on that? 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?
  - joecool1029 2y ago
    > What's the threat model of such an odd design choice? 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.
  - OptionOfT 2y ago
    > Yeah, but are there any official docs on that? 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/89d7e96b25594e51a7e8db6b227f06aeab79c543/apps/desktop/desktop_native/src/password/windows.rs#L81 https://github.com/bitwarden/clients/blob/89d7e96b25594e51a7... [1] https://gist.github.com/micjabbour/654e67d29cbd62be3587b9f1dd79eaac https://gist.github.com/micjabbour/654e67d29cbd62be3587b9f1d...
  - palata 2y ago
    > What's the threat model of such an odd design choice? Are there any docs on that? 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.
joecool1029 2y ago
> If I wanted to know how the database is encrypted in their apps, do I find an overview on that? 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/ https://www.zetetic.net/sqlcipher/design/

OptionOfT 2y ago

FYI, last time I checked Signal's sqlite database was encrypted with SQLCipher [0] 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. [0] https://github.com/sqlcipher/sqlcipher https://github.com/sqlcipher/sqlcipher

melgafin 2y ago
Yeah, but are there any official docs on that? 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?
- joecool1029 2y ago
  > What's the threat model of such an odd design choice? 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.
- OptionOfT 2y ago
  > Yeah, but are there any official docs on that? 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/89d7e96b25594e51a7e8db6b227f06aeab79c543/apps/desktop/desktop_native/src/password/windows.rs#L81 https://github.com/bitwarden/clients/blob/89d7e96b25594e51a7... [1] https://gist.github.com/micjabbour/654e67d29cbd62be3587b9f1dd79eaac https://gist.github.com/micjabbour/654e67d29cbd62be3587b9f1d...
- palata 2y ago
  > What's the threat model of such an odd design choice? Are there any docs on that? 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.

joecool1029 2y ago

> If I wanted to know how the database is encrypted in their apps, do I find an overview on that? 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/ https://www.zetetic.net/sqlcipher/design/