Hacker News Reader

Comment by okatsu | Hacker News Reader

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.

View on HN

> 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.

> 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.

> 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.

> 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

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.

> 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.

At which point you have essentially decayed to conventional PKI and don't get any the security properties that you were supposed to get from the fancy Signal protocol (i.e. PFS).

Well, you always have to verify keys. No security is guaranteed without it. That is the case everywhere. Those pre-keys are just there to start a session, which in my communication with my brother case has lasted for as long as I had my phone (about 3 years). That session creates new key material with every message, providing forward secrecy.

I think it is a pretty elegant solution to key distribution, even though I wouldn't plan any bomb attempts without first validating the fingerprints.

The fancy protocol gives you PFS by generating new keys for each messaging round trip between parties. Anything in flight is subject to decryption if you can grab the keys from an endpoint before they're cycled.

The upside is that users can communicate with each other without needing both endpoints online simultaneously (which is fairly hard to guarantee, given all the battery saving stuff in mobile OSes and lack of 100% network coverage).

The downside is the key cycle time is much longer than they would be if all communications were done with both parties online, but it's still much shorter than a conventional PKI (ex PGP).

So how fast does cycling happen if the server is under an attacker's control and trying to ensure that cycling is delayed as long as possible? It's messy and complicated, and certainly doesn't leave you with the simple "messages can never be read in the future" security property that Signal's advocates claim.

Regular key rotation is good practice when using PGP or similar - have a master key that you use only for signing subkeys, generate a new subkey every month (say) and destroy the ones older than 2 months each time - though admittedly UI/tool support for doing this is limited.

> So how fast does cycling happen if the server is under an attacker's control and trying to ensure that cycling is delayed as long as possible?

If you're getting bi-directional communication with your partner, you're getting key cycling. The server can only delay key cycling in a session by delaying one direction of communication.

The server can't hand out the same pre-key to multiple users, because the client will delete pre-key pairs on first use, with the exception of a "last resort" pre-key. The server could exclusively hand out the last resort pre-key to all users attempting to contact you, and refuse to accept new pre-keys. Then the first flight of messages from users establishing a new session would not be PFS, but any messages sent once you respond would have PFS.

Adding, of course, the server could also hand out incorrect keys and man in the middle all the steps; so long as users don't verify the keys. And a malicious client and server could conspire to include the correct keys for verification and the MITM keys for transport. This would be visible in the shipped code, but if the backdoored client is only distributed to a limited set of users, it wouldn't be subject to random reverse engineering like the normal client is. But I assume everybody downloads multiple copies of apks from different networks and compares to ensure they're byte identical ;)

> If you're getting bi-directional communication with your partner, you're getting key cycling. The server can only delay key cycling in a session by delaying one direction of communication.

That implies the client has to have a code path for sending multiple messages without cycling. And it forces a tough choice between losing messages that are received out of order and not destroying keys quite as quickly as nominally expected.

Maybe it's fine, but for me it pushed the complexity threshold over the point where I could feel any confidence in it. I'm comfortable with traditional PKI. I'm comfortable with the online-only OTR/axolotl ratchet. But I'm very dubious of having this many edge cases.

> The server could exclusively hand out the last resort pre-key to all users attempting to contact you, and refuse to accept new pre-keys. Then the first flight of messages from users establishing a new session would not be PFS, but any messages sent once you respond would have PFS.

Assuming there's no way for the client to end up on the initial-message codepath.

Again, yeah, maybe it's fine. But it all just feels so hacky and fiddly. These edge cases aren't where anyone studying the protocol is going to spend any time, but it's security-critical that they be implemented right.

I just re-read your message, and thought I should clarify: The client has two ratchets going. One is an opportunistic DH ratchet, and the other is a hash-based one that provides forward secrecy if the contents of the last DH ratchet was not intercepted and decrypted. Which, if you have verified the keys and no device key change has happened, it hasn't.

If you have a successful compromise of one message, a missed message is all it takes for the ratchet to self-heal and you have lost the ability to decrypt future messages. It is PFS+ in a sense.

Reply on news.ycombinator.com