[okatsu]

The article isn't about bad encryption though. It's not about a flaw in the signal protocol or something like that. It's stuff like Moxie doesn't like F-Droid. Which is not an invalid criticism but I'm not gonna stop recommending Signal over Facebook Messenger because of that.

Regarding false sense of security...eh. I can't speak for endangered activists but everyday people write stupid things whether it's on SMS or Signal. But might as well be on Signal.

[lmm]

> The article isn't about bad encryption though. It's not about a flaw in the signal protocol or something like that. It's stuff like Moxie doesn't like F-Droid. Which is not an invalid criticism but I'm not gonna stop recommending Signal over Facebook Messenger because of that.

You have to look at the whole system, not just one algorithm that it uses - if any part of the system is secure then the whole is insecure. Do you believe Signal-the-system is meaningfully more secure than Facebook Messenger (which uses industry-standard HTTPS, so at the low-level protocol/algorithm level it's certainly secure enough)? If so, why/how? If not, why recommend it?

(I agree that Signal is more secure than SMS, but so is Facebook Messenger or any number of other messaging apps).

[okatsu]

Isn't the whole point of Signal that it's e2e encrypted and therefore can't really read and share your messages? Whereas Facebook's system is centralized? So yeah you're safe from outside attacks but not internal ones?

I mean if you're asking me if I know for certain that Signal is better than Facebook, there's no way for me to know for sure.

But at some point there is a level of trust required and I trust a company like OWS more than I trust a company like FB. Call it blind faith, I dunno, but I also have to trust my operating system otherwise I wouldn't get anything done.

Edit: although I should add that while it may be labeled as blind faith it's also fueled by experience. OWS aren't the ones that periodically reset my privacy settings or tried to wage war against accounts not using real names etc etc.

[lmm]

> Isn't the whole point of Signal that it's e2e encrypted and therefore can't really read and share your messages?

Maybe. They have an awkward, compromised design, because fundamentally you can only the key exchange stuff that's necessary for forward secrecy if you're both online at the same time, but of course they want to support offline messaging, so they have a protocol that's mostly-e2e but the server also participates in it in some cases. In theory maybe it's all fine, but it's complex and has a lot of surface area. Combine that with Signal keeping the server not-quite-open and being weirdly insistent on not having federation, and I'm suspicious.

> But at some point there is a level of trust required and I trust a company like OWS more than I trust a company like FB. Call it blind faith, I dunno, but I also have to trust my operating system otherwise I wouldn't get anything done.

Agreed, which is really what the article is about. I have very little trust in OWS and Marlinspike in particular because of his attacks on the most important/effective working cryptosystems we have (OpenPGP), and his willingness to compromise security properties that seem very important to me (open-source auditability, federation, stronger anonymity than a phone number has) for the sake of features that I think are less significant (forward secrecy), and his refusal to even acknowledge that a tradeoff is being made.

[bjoli]

> They have an awkward, compromised design, because fundamentally you can only the key exchange stuff that's necessary for forward secrecy if you're both online at the same time.

The initial key exchange is done through the server using "pre-keys" (which, unless verified, is trust on first use). Any new key data is sent with the messages (and as such, there is not much extra done by the server)

I don't see how signal could get any more auditability. Since they switched to webrtc-based VoIP the whole server is open source. They have made a lot more progress in letting the client verify what the server is running compared to any other messenger out there, unless you are able to run your own.

I would say that the goal of signal was more about making an encrypted secure messenger for my mom than making crypto nerds safe from targeted attacks by nation states.

[lmm]

> The initial key exchange is done through the server using "pre-keys" (which, unless verified, is trust on first use). Any new key data is sent with the messages.

How confident are you that the server can't trick the client into downgrading to a new trust-on-first-use exchange? I'd also ask what happens when one party sends multiple messages while the other is offline - eventually you must exhaust your preshared keys, at which point you have no good options - presharing more keys compromises forward secrecy, encrypting without more exchanges compromises forward secrecy, and it's very difficult to make it clear to the user what the tradeoffs are. And again, whatever approach you choose opens the door to downgrade attacks (particularly if we're assuming that the OWS servers are hostile - Signal fans always claim that you don't have to trust the server at all but then don't really commit to that when talking about these edge cases. If we really aren't trusting the server then we should assume the servers are under attacker control when analysing these edge cases)

> I would say that the goal of signal was more about making an encrypted secure messenger for my mom than making crypto nerds safe from targeted attacks by nation states.

Slurs against those who disagree with you do not improve your case.

Are there any messengers that don't use TLS left? (Even IRC servers tend to use it these days). Your mom is adequately served by transport encryption. The Venn diagram of people who need more security than transport encryption and people who can safely use phone numbers as identifiers looks like: OO

[toast0]

Prekeys are to start a session with someone, it's basically a public key. You generate a new public private keypair, do a DHE to establish the session secrets, send your new public key along with the encrypted message. If you send more messages to the same person, they use the same session.

TLS is fine enough for messages in flight, but a lot of messengers store message archives on their servers, and there may be tens of thousands of employees who have potential access to that; not sure if that's really what anybody's mom needs.

[toast0]

> Combine that with Signal keeping the server not-quite-open and being weirdly insistent on not having federation, and I'm suspicious.

I'm not exactly sure what not-quite-open means (I thought the code was available, do you mean the server won't accept modified clients?), but Signal was federated once, with Cyanogen, and they opted not to continue the federated model. I don't think it's weird to not want to coordinate upgrades across servers in multiple organizations. Looking at existing federation models that mostly work, we have things like email, where there's no coordination and some servers never get upgraded, leading to a very low lowest common denominator; there's also IRC, where servers in a network really need to run the same software and are upgraded in lockstep -- that's fine enough if everyone is on board, but it doesn't look that much different than one organization running the servers.

[tialaramex]

Evidently Facebook themselves don't agree with you, since their "Secret Conversations" feature uses Signal's protocol (many other systems also have equivalent features built out of Signal Protocol, Skype, Google Chat, XMPP ... it's a sort of trend)

In terms of how Signal compares to something like Facebook Messenger using HTTPS that's an actual technical question that's worth talking about (whereas "Oh no, Moxie Marlinspike is a mean person who hates F-Droid" is basically just noise)

HTTPS gives us two ingredients, both relevant here, TLS and HTTP. TLS is intended to deliver privacy and data integrity between two parties, it does a pretty good job at that, but it's very common to have configurations which do not result in Forward Secrecy. This means messages that couldn't be read by any potential adversary today could become readable tomorrow - long after both parties don't need them any more - if the adversary obtains a long term key. Your web browser might, possibly, tell you about this risk if you ask, but it definitely won't flag it in the main UI. Next, Facebook is authenticated to you by its proof of possession of a Private Key corresponding to the Public Key in a certificate from a Trusted Third Party CA. An adversary could corrupt this CA, but hopefully that's difficult.

Now, why does HTTP even matter? Well, although TLS _can_ authenticate both parties, on the Web today we rarely do that. Instead the web server is authenticated using TLS but the client (a Facebook user) has some crummy HTTP layer authentication, maybe a password like "1LvUrDog" filled into an HTML form field.

So, between those two cracks, if the Secret Police either steal your brilliant canine-related Facebook password or get Facebook to give them a long term key, they can read all your Facebook Messenger chat, eavesdropping on it indefinitely.

Signal doesn't use passwords. Your device has randomly picked a Private Key, but unlike Facebook you don't have a certificate from a CA, instead you can compare the associated Public Key on your device with that shown for another participant on their phone, if they don't match there's a Man in the Middle. So immediately that's an improvement, no password guessing.

Signal also has Forward Secrecy. In fact each message sent and received changes the keys used for future messages. As a result an adversary can only eavesdrop by actively impersonating one of the participants. In a two person conversation that's often likely to become obvious pretty quickly whereas passive eavesdropping is undetectable.

[lmm]

> although TLS _can_ authenticate both parties, on the Web today we rarely do that. Instead the web server is authenticated using TLS but the client (a Facebook user) has some crummy HTTP layer authentication, maybe a password like "1LvUrDog" filled into an HTML form field.

I would love to see more use of client certificates, but assuming good password practice is there a real security difference? Either way both parties authenticate themselves to the other.

> Next, Facebook is authenticated to you by its proof of possession of a Private Key corresponding to the Public Key in a certificate from a Trusted Third Party CA. An adversary could corrupt this CA, but hopefully that's difficult.

And hopefully Certificate Transparency would catch them if they did.

> Signal doesn't use passwords. Your device has randomly picked a Private Key, but unlike Facebook you don't have a certificate from a CA, instead you can compare the associated Public Key on your device with that shown for another participant on their phone, if they don't match there's a Man in the Middle. So immediately that's an improvement, no password guessing.

Well, depends what you're trying to verify. Verifying that someone is always using the same device is one choice with its own set of tradeoffs (e.g. many people change devices quite often). Verifying that someone always knows a given password is another. I think tied-to-device keys lose you more than you gain, though I appreciate there's room for disagreement here.

> Signal also has Forward Secrecy. In fact each message sent and received changes the keys used for future messages. As a result an adversary can only eavesdrop by actively impersonating one of the participants. In a two person conversation that's often likely to become obvious pretty quickly whereas passive eavesdropping is undetectable.

You don't have to actively participate as such - you can just forward messages between the two. And Signal's servers are already sitting in the right place to do that.

In theory PFS is a valuable benefit. But the level of compromise needed to incorporate it into a practical system where people want to be able to send offline messages and messages to new contacts who they haven't exchanged keys with beforehand... IMO the resulting level of protocol complexity compromises your security more than the fairly weak guarantees you get out of it in practice are worth. Certainly not when the cost is no federation and identity-tied-to-phone-number.

[tialaramex]

OK, so yes, if you steal Alice's credentials AND have control over the co-ordinating server you can trick Alice and Bob into continuing to communicate with you in the middle, and so long as you keep this up it's relatively undetectable.

I think I can see how to repair this (Alice doesn't know Bob's private key, but she does know a long term public key for him, as a result she could periodically and automatically re-verify that she's still talking to Bob and not just someone who has her short term keys and is actively conducting a MITM) but Signal doesn't attempt such a repair and maybe I'm wrong.

[tialaramex]

Edited: Hmm. I wrote a long claim here and now I'm not sure depending on exactly what you steal, from whom, and when. I will re-think and re-post this.