Live data from Hacker News

I don't trust Signal

drewdevault.com

431–440 of 473 posts

Re: I don't trust Signal

#431

"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 saying "Ok, North Korea has some small nukes, but if they really want to get serious about a nuclear attack, they can always penetrate the White House and steal the nuclear football from under Trump's ass".

Re: I don't trust Signal

#432
post #394
post #348

Earlier quoted context omitted.

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

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

Re: I don't trust Signal

#433
post #325
post #201

Earlier quoted context omitted.

I don't think that has anything to do with the desktop app specifically?

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

Re: I don't trust Signal

#434
post #406
post #160

Earlier quoted context omitted.

Note: my understanding of SGX is that this still requires trust of Intel. Still, far better than nothing

It also requires there to not be a hardware sidechannel exploit on the device running SGX... such as the variants of Spectre that have ben trickling out every few weeks now all year... so yeah: Moxie's trust of SGX is pretty damning.

As I understood it, the "trust" comes down to: "it has some limits, but it's strictly better than nothing". I wouldn't call that damning.

Re: I don't trust Signal

#435
post #358

Earlier quoted context omitted.

> GPG has an infinitesimally small user base. Many tech savvy users still struggle to use it correctly. Moxie has explicitly stated that his aim is not to build the perfect secure messenger app, but a messenger app that provides the greatest amount of security to the greatest number of users. But what's the threat model where Signal makes sense? For a less-than-nation-state attacker, basic TLS as virtually all messen…

There are nation-state attackers and nation-state attackers. Most oppressive regimes don't have the technological resources to perform complex attacks on relatively tough systems, but they can perform pervasive monitoring on layer 1, use dodgy certificates to undermine TLS and bribe or coerce corporate actors. Most people in functioning democracies aren't particularly worried about becoming the target of the full mig…

> they can perform pervasive monitoring on layer 1

Indeed (particularly as telecoms are often state-owned in those regimes), which is what makes phone-number-as-ID such a bad idea.

> use dodgy certificates to undermine TLS

Difficult in these days of certificate transparency and HPKP.

> bribe or coerce corporate actors

If that's your worry surely you want to rely on a big corporation rather than Signal. Look at e.g. Brazil having to block WhatsApp entirely because Facebook wouldn't play ball with them. Facebook has deep pockets that mean they can afford to do that kind of thing.

> Signal is a vast improvement over SMS, plaintext email

Agreed

> or any commercial messaging application,

Not convinced that there's a significant improvement here. Plenty of commercial messaging applications have encryption. If the server is under an attacker's control then you're vulnerable, but I'm not convinced that isn't the case with Signal too.

Re: I don't trust Signal

#436

Earlier quoted context omitted.

Pushing an app out to F-Droid is trivial. There is literally no defense for only using Google Play and unsigned binaries on his own website.

I believe that to use the same app, he requires google play? Am i missing something? You can export the app yourself from google play and it doesn't run unless you have google play installed. Am I missing something?

Does "the same app" refer to Signal? If so, you an run it without having Google Play installed (though it will be more battery-hungry), and download the APK yourself.

Re: I don't trust Signal

#437
post #234

Earlier quoted context omitted.

Fwiw, Matrix E2E actually exists in separate codebases in: Riot/Web, Riot/iOS, Riot/Android, nheko, matrix-python-sdk, libpurple (in PR), and shortly in Fractal (thanks to https://gitlab.gnome.org/jhaye/olm-rs etc). So yup, it sucks that it's not turned on by default in private rooms, but we're working away as fast as we can.

For the record, E2E is currently in libpurple master (only decryption not encryption) and in PR on matrix-python-sdk. Just a slight flip there.

my bad; i thought all the python ones had landed now. in practice the work is done.

Also, since writing this list yesterday, another client has got E2E running: Seaglass (a native Cocoa macOS client): https://neilalexander.eu/seaglass/

Re: I don't trust Signal

#438
post #80

Earlier quoted context omitted.

According to friends in the cryptography space and from a cursory reading of wikipedia, Telegram is a shitshow compared to Signal. It's one thing not to trust Signal. It's another to recommend alternatives that are far worse.

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

Re: I don't trust Signal

#439
post #423
post #412

Earlier quoted context omitted.

>The whole "we use nacl so we are safe" attitude from a couple of years ago seems to still be around. Citation needed. >Well. I'd rather not have anyone suggest tox. I'm repeating myself, but for all the hate it gets, I'm unable to come up with a better suggestion than Tox. There's always some kind of flaw: Centralized, no forward secrecy, end to end encryption optional, no way to verify contacts and so on.

Regarding the citation, it is just a matter of reading how the core devs reply to potential security issues. Sure, it has gotten better, but it is not too far from the good old https://github.com/irungentoo/toxcore/issues/121 The fact is we mostly know what kind of attacks are possible on signal. We know metadata is a potential problem. We know what kind of tradeoffs we get with a centralised architecture. We know ho…

>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 until the amount of unknowns is smaller.

I don't see how the likes of Signal or the popular Telegram are any better in that regard. Also, adding more features (your phone suggestion) wouldn't help.

Re: I don't trust Signal

#440
post #424

Earlier quoted context omitted.

I would trust Signal on iOS, depending on who I was messaging. I'd turn on timed messages though, and the signal number wouldn't be my main phone number. Far less likely to be key logged on iOS. If you don't browse websites on the device that helps. You have to consider that face to face meetings are often observed by third parties, you can be tracked easily, extremely incriminating generally. The other person can ta…

The other person can show your signal messages to the wrong people just as well as they can talk about the conversation. At least with a conversation, you have plausible deniability although that may not count for much. You do also have to be careful of being recorded. Still, the point is, I would not trust a software platform. Ios or Android doesn't make a difference. They are both easily exploitable and have tons o…

I don't think many experts would call iOS "easily exploitable", especially if you don't install random apps and browse the web. 0-days aren't easily available for places like Iran, Syria, Egypt, etc, or even larger countries like Brazil, and wouldn't be burnt on any ordinary suspect. They still usually rely on the user clicking a link. A locked down iPhone (no BT, WPA2-EAP, VPN, Signal, hard passphrase) is a hard target.

If your contact is the type who will record the fading Signal messages with another phone you're already fucked.

Post reply on HN