Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don't trust Signal

drewdevault.com

Post reply on HN
Print view View original

451–460 of 473 posts

Re: I don't trust Signal

#451

Post by leshow »

Hello71 wrote: post #329
leshow wrote: post #299

Earlier quoted context omitted.

It seems pretty odd to me to distrust someone because they aren't using the platform that you'd like them to use. Aren't there other issues with f-droid? You have to root your device to run it, allow third party code. Those are all security concerns too. It was posted elsewhere but here's Moxie's take: https://github.com/signalapp/Signal-Android/issues/127#issue...

> You have to root your device to run it wtf. I have been using F-Droid for many years, and this has not been the case. as far as I know, this has never been the case, as Android has always had functions for third party app stores. in fact, even today, F-Droid recommends not using root for installs, since then you don't get the screen showing permissions. > allow third party code that's called running apps. tl;dr nic…

> that's called running apps.

And you accuse me of making things up? "Allow third party code" is not called "running apps"

Re: I don't trust Signal

#452

Post by pmlnr »

Vinnl wrote: post #433
pmlnr wrote: post #325

Earlier quoted context omitted.

It does. Desktop app is desktop, end of story - no GSM connection and/or phone number should be required.

It sounds like you'd also be against requiring phone numbers if they didn't have a desktop app...

A phone app requiring a phone number is reasonable; it doesn't matter if I like it or not.

On a desktop app, it's not reasonable to ask for a phone number. Ask for something else; email, for example.

Re: I don't trust Signal

#453

Post by snvzz »

bjoli wrote: post #447
snvzz wrote: post #439

Earlier quoted context omitted.

>Sure, it has gotten better, but it is not too far from the good old So your citation for sticking to their old ways is pointing to some old example? That's not what I was looking for. >Why aren't the devs clear about using a less distributed architecture for mobile clients? Because it's not a priority to them; Or to me, for that matter. (I don't IM on the phone) >I would not recommend it for secure communication unt…

Signal is better because people who knows their shit has vetted the design and quite a bit of research on the protocol has been done. We a quite certain of the security properties of the signal protocol. Tox has not had this amount of attention and it is written by people who seemed to sincerely believe that using nacl/libsodium made tox safe. If that is not a huge red flag, then I don't know what is. Telegram is not…

>Signal is better because people who knows their shit has vetted the design

So basically, argument from authority. No Good.

Re: I don't trust Signal

#454

Post by moogly »

Vinnl wrote: post #442
moogly wrote: post #387

As a Signal user, I just wish I could make my own personal fork of the desktop app and still talk to everyone without having to use the beta servers and fear of having access cut off, because the visual design and UX of the desktop app is absolutely atrocious. And the latest update that was pushed a few days ago was a massive step back; the bloated UI now looks like some iOS app from 2007. It's just embarrassing. And…

Hmm, if you can improve the UI by yourself, could you not submit a pull request to do that? That would probably still allow you to use the improved UI without fear of having access cut off. (I wasn't aware of a redesign - just updated, and I don't really like it either, but ah well.)

In theory yes, but I don't think the team would appreciate any old random schmuck to change their product's look-and-feel :)

Re: I don't trust Signal

#455

Post by toast0 »

lmm wrote: post #432
toast0 wrote: post #394

Earlier quoted context omitted.

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 ten…

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

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

Re: I don't trust Signal

#456

Post by lmm »

toast0 wrote: post #455
lmm wrote: post #432

Earlier quoted context omitted.

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

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…

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.

Re: I don't trust Signal

#457

Post by toast0 »

lmm wrote: post #456
toast0 wrote: post #455

Earlier quoted context omitted.

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…

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 sig…

> 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 ;)

Re: I don't trust Signal

#458

Post by bjoli »

snvzz wrote: post #453
bjoli wrote: post #447

Earlier quoted context omitted.

Signal is better because people who knows their shit has vetted the design and quite a bit of research on the protocol has been done. We a quite certain of the security properties of the signal protocol. Tox has not had this amount of attention and it is written by people who seemed to sincerely believe that using nacl/libsodium made tox safe. If that is not a huge red flag, then I don't know what is. Telegram is not…

>Signal is better because people who knows their shit has vetted the design So basically, argument from authority. No Good.

Then I ask you: as a non-cryptographer who knows enough to understand RSA, how should I verify cryptographic claims? People i find trustworthy claim signal is good, which is further confirmed by studies and third party suits. I know this is an appeal to authority, but nobody can personally verify every claim made to them. I believe I have done due diligence.

Re: I don't trust Signal

#459

Post by lordlimecat »

milcron wrote: post #409
lordlimecat wrote: post #372

Earlier quoted context omitted.

Whats odd is calling a application "not secure" because it uses the platform's software distribution channel. Here's a thought. If you are so concerned about the NSA that you think Google's cloud is a problem, why are you running the OS developed by Google?

The open-source base OS is fine, the closed-source services layer and cloud platform are not.

Sounds like you're confident you (or the FOSS community collective) can spot cleverly hidden backdoors.

I'm not, and I find that position naieve. For the overwhelming majority of people who are not a cross between Bruce Schneier and Linus Torvalds, a threat model that tries to protect against the NSA and GRU and MSS pretty much requires avoiding anything with a network connection. If you have a smartphone, you should probably just use its default application store.

Re: I don't trust Signal

#460

Post by snvzz »

bjoli wrote: post #458
snvzz wrote: post #453

Earlier quoted context omitted.

>Signal is better because people who knows their shit has vetted the design So basically, argument from authority. No Good.

Then I ask you: as a non-cryptographer who knows enough to understand RSA, how should I verify cryptographic claims? People i find trustworthy claim signal is good, which is further confirmed by studies and third party suits. I know this is an appeal to authority, but nobody can personally verify every claim made to them. I believe I have done due diligence.

It helps that they used NaCl. When cryptographers looked at it, they found an issue: People can impersonate your friends if they get their hands on your private key.

This is pretty bad, but so is having had your private key compromised in the first place. It should be fixed next time they do a flag day.

Other than that, and the rekeying issue (keys are only renewed when the client is closed. They should be on a period of time, to make forward secrecy really effective), nothing else bad was found.

Notice that, for a couple years now, effort has gone into polishing (toktok) toxcore and documenting things, rather than else (eg: adding fancy features). That's a good thing.

Tox might be understaffed and progressing slowly, but there's nothing fundamentally bad about it. They got a bunch of important things (really distributed, DHT, public keys as addresses, temporal keys for forward secrecy, always end to end encrypted) right. I'm not aware of any other project that got this much right, unfortunately.

If only if Tox got more attention, it'd gain developers, donations, and the possibility of getting a proper audit done.

Post reply on HN