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

461–470 of 473 posts

Re: I don't trust Signal

#461

Post by velosol »

pdkl95 wrote: post #153
Vinnl wrote: post #100

Earlier quoted context omitted.

What do you mean by a "connected" web interface? And what would being a desktop application bring it? Signal Desktop is somewhat buggy, not that full-features, and doesn't integrate that well with the rest of my OS, but otherwise it's working fine, and I can use it simultaneously with my phone. (But I can also use it with my phone turned off, which I love.)

> but otherwise it's working fine It doesn't work at all for me, because it requires a mobile phone number, which I don't have (a phone + any monthly subscription fee doesn't fit in a tiny fixed income budget).

I understand you may not have a phone number at all, but Signal doesn't actually require that you have a mobile phone number at all. It can be a landline or VOIP line that can receive a call and you get a voice verification.

Of course many don't want to tie their communications to some other identifier and that's fine but that does mean that Signal isn't for those people.

Re: I don't trust Signal

#462

Post by lmm »

toast0 wrote: post #457
lmm wrote: post #456

Earlier quoted context omitted.

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…

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

Re: I don't trust Signal

#463

Post by tabletopneedle »

bumholio wrote: post #431
tabletopneedle wrote: post #370

"Google Play Services lets Google do silent background updates on apps on your phone and give them any permission they want. Having Google Play Services on your phone means your phone is not secure." Yes, Google can install a backdoored version of Signal. This is bad. But if you can't take that risk, you can install e.g. LineageOS without Google Apps, download the source code, reproducibly compile the apk, and instal…

I stopped reading after: All your suggestion does is, it adds a layer or two where we hope the NSA doesn't compromise them in case you'd want to use that chain to install and validate Signal. You can't possibly think that compromising the full infrastructure of MIT or F-Droid, a noisy criminal act with serious repercussions against the perpetrators, is in any way comparable to a MITM against a suspect. That's like sa…

You can't possibly say one needs to compromise MIT's entire infrastructure when all it needs is MITM attacks against the browsing session. That doesn't require compromising either if you have a CA private key the client's browser trusts. Only if there is certificate pinning do you need the server's key, and even at that case you only need to compromise the private key of the university. You don't have to compromise every system to do that. Compromising only a single system among the small group of systems that hold the private key will do.

Your comparison is as thoughtless as the rest of your reply.

Re: I don't trust Signal

#464

Post by oakpond »

Gaelan wrote: post #165
thsealienbstrds wrote: post #142

Earlier quoted context omitted.

If I read that document correctly, it's more accurate to say that Signal stores at least two integers, rather than exactly. Signal did not provide information that does not fall under certain information categories, and they say that a court order would be needed to force them to disclose any of that information (if they possess any, which they deny).

But they did deny possessing any of that information in the subpoena reply, so if you trust that they are replying truthfully it is exactly 2.

So, nobody has ever lied in a subpoena reply before?

Re: I don't trust Signal

#465

Post by cannonedhamster »

angry_octet wrote: post #441
ficklepickle wrote: post #416

Earlier quoted context omitted.

Then you "untick" it until the next time you need to install something. This is what I do on lineageOS. I don't regularly install new apps. Side rant: This marketer-driven "install an app for everything" is a threat to the open internet and privacy. Usually the only reason is to extract more personal info. Already, young people barely use a web browser. That appears to be the future. Now get off my lawn or I'll start…

You might do it, but thousands wouldn't. Android could undoubtedly be stronger in this regard, and in permission control, firewall, ad blocking etc, but it's not going to happen. Apps wouldn't be so bad if they were actually sandboxed properly, but yeah, they suck. I was interested in Copperhead OS as an alternative, but it seems to have fallen into a greed induced mess.

You just shot your own argument against his point in the foot. Thousands of people doesn't even make up a percentage point of the users of Android. Most people on Android use Google Play because it's sufficient against the threats that they need to it be sufficient against. Most people are okay with the risk/reward ratios that come with using commercial software because they then don't have to think about it. Signal provides a nearly turnkey level of protection above and beyond standard messaging in an easy enough format for most people to use.

Re: I don't trust Signal

#466

Post by angry_octet »

cannonedhamster wrote: post #465
angry_octet wrote: post #441

Earlier quoted context omitted.

You might do it, but thousands wouldn't. Android could undoubtedly be stronger in this regard, and in permission control, firewall, ad blocking etc, but it's not going to happen. Apps wouldn't be so bad if they were actually sandboxed properly, but yeah, they suck. I was interested in Copperhead OS as an alternative, but it seems to have fallen into a greed induced mess.

You just shot your own argument against his point in the foot. Thousands of people doesn't even make up a percentage point of the users of Android. Most people on Android use Google Play because it's sufficient against the threats that they need to it be sufficient against. Most people are okay with the risk/reward ratios that come with using commercial software because they then don't have to think about it. Signal…

IDK what you're going on about. What is your argument?

I am arguing Play store is fine, and side loading is bad policy.

I argued that for every person who will take the time to micromanage permissions, thousands wouldn't.

So what are you talking about?

Re: I don't trust Signal

#467

Post by carapace »

verbify wrote: post #438
carapace wrote: post #272

Earlier quoted context omitted.

(Totally unrelated, sorry, but about a month ago you and I had a brief exchange about the placebo effect.[1] I got distracted and missed your last reply and never responded. Sorry about that. It's too late to reply on the original thread, and I don't want to hijack this one, but while looking for an old comment I saw your reply and felt compelled to mention it to you. It was a good exchange IMO and I didn't mean to "…

I appreciate the apology, but I don't feel ghosting on an online conversation should require an apology. People have other lives, most often online discussions go way past their due date (I actually like the fact that HN doesn't give you a notification when somebody replies to your comment). It was a good discussion though, the placebo effect is fascinating.

Yeah, I almost let it go but then I figured, what's the harm? It was a good discussion. Well met.

Re: I don't trust Signal

#469

Post by bjoli »

lmm wrote: post #462
toast0 wrote: post #457

Earlier quoted context omitted.

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

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

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.

Re: I don't trust Signal

#470

Post by eighthave »

lorenzhs wrote: post #355
xorcist wrote: post #334

Earlier quoted context omitted.

That's not the interesting question. How easy is it to verify that the APKs are built from the published source code, without any added funny business? The F-Droid devs put a lot of work on reproducible builds. Not all software complies, but with an interest in information security there's no exucse not to. That's the use case of F-Droid, and comparing it to self publishing APKs without even as much as a GPG signatur…

https://signal.org/blog/reproducible-android/ makes it very easy.

That blog post is deceptive. Their instructions only reproduce the Java part, which is pretty easy to do. But Signal requires libraries written in C (aka "native code"), and they do not have that building reproducibly. The only Android messenger really doing reproducible builds is Briar.
Post reply on HN