> Stop with the astroturfing. Telegram is significantly worse in all of these points and is run by a thoroughly untrustworthy company.
I didn’t mention Telegram or any other client. Please read HN guidelines:
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
We do know that signal is lying:
- About it's code being open source
- About it's protocol being open
- About it's funding
- About it's massive white washing campaigns in forums
- About smear campaigns against and harassment of journalists who dare to look into them
We do know that signal is probably insecure if(!)
- It is actually based on the original white paper
- It is actually using any of the code they released ages ago
There have been major security incidents with apps using the signal protocol,
e.g. WhatsApp.
Who is the one doing the astroturfing?
You might not like the facts, but that doesn't change them.
And none of that code can be converted to something that is even close to the published app.
They might as well just release the source code for the firmware of a fridge.
Last time I checked, everything but the secret chats was not E2EE. So for the most part, it's effectively not secure. For the secret chats you're right, we don't know.
> signal is lying: - About it's code being open source
I compile and run Signal from the sources...
> About it's protocol being open
Are you talking about the Signal protocol here?
> We do know that signal is probably insecure if(!) - It is actually based on the original white paper
The point was:
This is a discussion about Signal, not Telegram.
But by now we have gotten pretty used to deflecting every discussion about "is Signal secure" to "look behind you, a three headed monkey" or rather to "but telegram is not secure, because all Russians are stupid".
"I compile and run Signal from the sources..."
Yes, so you get a messaging app that might be secure, while 99.999% of users use the one from the store which very likely comes from a completely different source.
"The original whitepaper"
Just use you favourite search engine, we have been over this dozens of times by now.
If you understand security I would start here: https://cs.nyu.edu/~afb383/publication/uc_signal/uc_signal.p...
If not -- it probably takes 15-25 years to teach you.
Very rough, and simplified:
"Double Ratchet has some very strong preconditions which have never been addressed by signal, and probably never been implemented by anybody." (Please, don't quote me on that, it's very dumbed down.)
> Yes, so you get a messaging app that might be secure
I was answering to... well to what I quoted: "signal is lying: - About it's code being open source". So it is obviously open source enough that I can compile it from sources.
> "The original whitepaper"
I did not write this either, were you answering to me? I am a little confused.
I don't have anything against Telegram personally, but that sentence is by all intents and purposes equivalent to "Telegram is not secure".
Meanwhile, every person I have met at my past affiliations who did research in security was using Signal as their main IM app. Blind trust is always bad, but I don't think that crowd was using it just for cargo-culting.
TBF, I’ve just read multiple pages of bio and I’m still unsure what qualifications Whittaker has to be president of Signal (or previously such a senior position at Google), apart from a firebrand approach to tech issues.
She has a bachelor’s degree in “rhetoric” and a few papers whose titles read like buzzfeed articles.
> We literally have no idea who makes [insert your favourite chat program here] or what their credentials are that make them qualified to make a chat app where encryption is supposed to be the "core" feature
> Signal spokesperson Jun Harada wrote in an email: “Intel alerted us to this paper... and we were able to verify that the CPUs that Signal uses are not impacted by the findings of this paper and therefore are not vulnerable to the stated attack.”
Not true. Molly works Signal-CLI works from what I've seen in the past.
They are unsupported, but not aggressively blocked. They are not allowed to be on the subreddit, probably because the subreddit is for SIGNAL and they don't want to deal with the headache of supporting users who use third party clients they cannot control.
In combination with 1488, it really isn't far fetched. It's convenient that it has gained other meanings, but it's absolutely being used as a way of identification in nazi circles, and as a meme in adjacent spaces (i.e. the leaked group chats of "Itiotentreff", consisting mostly of far right police officers in Frankfurt)
If you think this is a stretch and ridiculous I can't change your mind, except say that's the point of using coded language like that.
Picking one point from there, possibly the one least connected to Signal:
> 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.
"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/). 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.)
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.
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?
> 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.
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?).
> 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.
> 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/
I’m really tired by FUD spread by Signal’s executives when they literally do not care about usability or client side security;
- 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.
Do I understand correctly that you are complaining about Signal as a protocol by mentioning the export feature on iOS and the encryption at rest on Linux?
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"?
47 comments
[ 4.3 ms ] story [ 104 ms ] threadI didn’t mention Telegram or any other client. Please read HN guidelines:
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
We do know that signal is lying: - About it's code being open source - About it's protocol being open - About it's funding - About it's massive white washing campaigns in forums - About smear campaigns against and harassment of journalists who dare to look into them
We do know that signal is probably insecure if(!) - It is actually based on the original white paper - It is actually using any of the code they released ages ago
There have been major security incidents with apps using the signal protocol, e.g. WhatsApp.
Who is the one doing the astroturfing?
You might not like the facts, but that doesn't change them.
> code they released ages ago
Last time I checked, everything but the secret chats was not E2EE. So for the most part, it's effectively not secure. For the secret chats you're right, we don't know.
> signal is lying: - About it's code being open source
I compile and run Signal from the sources...
> About it's protocol being open
Are you talking about the Signal protocol here?
> We do know that signal is probably insecure if(!) - It is actually based on the original white paper
Can you elaborate on that?
The point was: This is a discussion about Signal, not Telegram.
But by now we have gotten pretty used to deflecting every discussion about "is Signal secure" to "look behind you, a three headed monkey" or rather to "but telegram is not secure, because all Russians are stupid".
"I compile and run Signal from the sources..." Yes, so you get a messaging app that might be secure, while 99.999% of users use the one from the store which very likely comes from a completely different source.
"The original whitepaper" Just use you favourite search engine, we have been over this dozens of times by now. If you understand security I would start here: https://cs.nyu.edu/~afb383/publication/uc_signal/uc_signal.p... If not -- it probably takes 15-25 years to teach you.
Very rough, and simplified: "Double Ratchet has some very strong preconditions which have never been addressed by signal, and probably never been implemented by anybody." (Please, don't quote me on that, it's very dumbed down.)
I did not write that, were you answering to me?
> Yes, so you get a messaging app that might be secure
I was answering to... well to what I quoted: "signal is lying: - About it's code being open source". So it is obviously open source enough that I can compile it from sources.
> "The original whitepaper"
I did not write this either, were you answering to me? I am a little confused.
I don't have anything against Telegram personally, but that sentence is by all intents and purposes equivalent to "Telegram is not secure".
Meanwhile, every person I have met at my past affiliations who did research in security was using Signal as their main IM app. Blind trust is always bad, but I don't think that crowd was using it just for cargo-culting.
Doesn't help the encryption is very badly designed, possibly on purpose: https://words.filippo.io/dispatches/telegram-ecdh/
She has a bachelor’s degree in “rhetoric” and a few papers whose titles read like buzzfeed articles.
It is the same for all.
What weird crypto system?
Not true. Molly works Signal-CLI works from what I've seen in the past.
They are unsupported, but not aggressively blocked. They are not allowed to be on the subreddit, probably because the subreddit is for SIGNAL and they don't want to deal with the headache of supporting users who use third party clients they cannot control.
They seem to support reproducible builds https://github.com/signalapp/Signal-Android/blob/main/reprod...
> and don’t allow third party compiled to connect
They don't want 3rd party clients to connect official servers, and do not support to them, but there is no outright ban.
In combination with 1488, it really isn't far fetched. It's convenient that it has gained other meanings, but it's absolutely being used as a way of identification in nazi circles, and as a meme in adjacent spaces (i.e. the leaked group chats of "Itiotentreff", consisting mostly of far right police officers in Frankfurt)
If you think this is a stretch and ridiculous I can't change your mind, except say that's the point of using coded language like that.
Folks, this is how dog whistles are supposed to work.
> 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.
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.
[0] https://github.com/sqlcipher/sqlcipher
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"?