Hacker News Reader

Comment by monero-xmr | Hacker News Reader

Wasn’t it a couple years ago the intelligence community was arguing for backdoor mandates, and now the FBI recommends Signal for safe chats? Such a farce. Hopefully the new admin goes through their emails and text messages over the last 4 years. Privacy for me, not for thee, I suppose…

View on HN

"...implies that the attack wasn't against the broadband providers directly, but against one of the intermediary companies that sit between the government CALEA requests and the broadband providers"

Yup. The attack hit the CALEA backdoor via a wiretapping outsourcing company. Which one?

* NEX-TECH: https://www.nex-tech.com/carrier/calea/

* Substentio: https://www.subsentio.com/solutions/platforms-technologies/

* Sy-Tech: https://www.sytechcorp.com/calea-lawful-intercept

Who else is in that business? There aren't that many wiretapping outsourcing companies.

Verisign used to be in this business but apparently no longer is.

Thank you for posting this. The search term "calea solutions"[1] also brings up some relevant material, such as networking companies advising how to set up interception, and an old note from the DoJ[2] grumbling about low adoption in 2004 and interesting tidbits about how the government sponsored the costs for its implementation.

[1] https://www.google.com/search?client=firefox-b-d&q=calea+sol...

[2] https://oig.justice.gov/reports/FBI/a0419/findings.htm

where from ""...implies that the attack wasn't against the broadband providers directly, but against one of the intermediary companies that sit between the government CALEA requests and the broadband providers" comes from ? from schneier ? because if you go to the actual reporting in wsj for example, it doesn't imply that attack was against TTP providers. also TTP providers are optional

WSJ: U.S. Wiretap Systems Targeted in China-Linked Hack https://www.wsj.com/tech/cybersecurity/u-s-wiretap-systems-t...

That seems pretty clear.

nope :)

wiretap systems are on the telecom provider side and it a bunch of different and in many cases ordinary networking equipment that can be easily misconfigured.

TTP (aka companies listed above) are optional and usually used by companies that don't have their own legal department to process warrants/want to deal with fine details of intercepts

> wiretapping outsourcing company

Is it a great idea to give all that info to India as well?

Nothing contradictory (in philosophy), really: they said American law enforcement should be able to break encryption when they have warrants and they now say Chinese spies should not be able to.

This is obviously technically impossible, but the desire for that end state makes a ton of sense from the IC’s perspective.

That something can simultaneously be impossible and sensible is peculiar. It almost suggests that the technique has merely not yet been figured out.

Secrets fail unsafe. Maybe an alternative doesn't.

It is sensible that people would want the impossible. It isn't sensible to try to mandate it.

Government keeps trying to mandate it in various ways. With predictably bad results.

How is it obviously technically impossible?

Whatever method is available to American law enforcement is eventually going to become available to Chinese spies. The record of keeping this kind of secret is abysmal. If by no other means, then by social engineering the same access that local police departments were supposed to have.

Salt Typhoon - which this discussion is about - is an example. Tools for tracking people that were supposed to be for our side, turn out to also be used by the Chinese. Plus the act of creating partial security often creates new security holes that can be exploited in unexpected ways.

Either you build things to be secure, or you have to assume that it will someday be broken. There is no in between.

Something either has X degree of security (for everyone) or it does not.

The FBI has a weird mandate in that it's both counter-espionage and counter-crime, and those are two quite different missions. Unsurprising to know that counter-espionage want great encryption, and counter-crime want backdoorable encryption.

You want the new anti democratic/authoritarian administration to look through the FBIs emails to find something to frame them for? You sure that's wise? Even if they don't respect privacy like they should?

It seems like every few years law enforcement puts out statements about how good encryption is for criminals, and then they have to walk it back as data breaches happen.

Sometimes you're on offense, sometimes you're on defense. The government does both.

It doesn't take much to read between the lines on those two statements. Feds have access to Signal if they want it, but are using it as filter paper against most attacks against the public etc.

The "feds" do not have access to Signal, except by CNE attacks against individual phones. Signal's security does not rely on you trusting the Signal organization.

It's ok for someone to believe that, but I don't believe that. Unfortunately there is no practical way to verify it either.

Well, if you're in a position where you can only put faith in someone else's word as to whether it's good for your needs (this is the vast majority of people), there's this: https://community.signalusers.org/t/overview-of-third-party-...

What are you talking about? Signal is open source, and its cryptographic security is trivially verifiable. If you don't trust the nonprofit behind it for whatever reason, you can simply compile it yourself.

> and its cryptographic security is trivially verifiable

That's going quite far. Even with all the details of it documented and open, there's a relatively small number of people who can actually verify that both the implementation is correct and the design is safe. Even though I can understand how it works, I wouldn't claim I can verify it in any meaningful way.

Multiple teams have done formal verification of the Signal Protocol, which won the Levchin Prize at Real World Crypto in 2017.

Sure, there are teams who have done it. But it's not trivial. The fact there's a price for it shows it's not trivial. If I choose a random developer, it's close to guaranteed they wouldn't be able to reproduce that. The chances go to 0 for a random Signal user.

Alternatively: it's trivial for people sufficiently experienced with cryptography. And that's a tiny pool of people overall.

The idea isn't that you do formal verification of the protocol every time you run it. It suffices for the protocol to be formally verified once, and then just to run that one protocol. If you thought otherwise, you might as well stop trusting AES and ChaCha20.

It is possible for the core protocol to be tightly secure, while a bug in a peripheral area of the software leads to total compromise. Weakest link, etc. One-time formal verification is only sufficient in a very narrow sense.

It is also possible for a state-level adversary to simply hijack your phone, whatever it is, and moot everything Signal does to protect your communications. Cryptographically speaking, though, Signal is more or less the most trustworthy thing we have.

Just look at PuTTY and e521 keys.

Or go back to Dual_EC_DRBG.

Unless DJB has blessed it, I'll pass.

What do those two issues have to do with each other?

These were showstopper bugs that betrayed anything they touched.

Avoiding this is obviously a huge effort.

Dual EC was a "showstopper bug"?

It did stop openssl whenever you tried to use it in production mode ;)

If you compile it yourself, can you still connect to the Signal servers?

And, even if you can connect with your own client, can you trust the server is running the code they claim it is? They were caught running proprietary server code for a time in 2020-2021. https://github.com/signalapp/Signal-Android/issues/11101#iss... / https://news.ycombinator.com/item?id=26715223

But the client is designed to not trust the server, that's why encryption is end-to-end. So does it matter?

In some sense, no - the protocol protects the contents of your messages. In another sense, yes - a compromised server is much easier to collect metadata from.

Metadata, yes. Of course, the protocols, and thus all the inconveniences of the Signal app people constantly complain about, are designed to minimize that metadata. But: yes. Contents of messages, though? No.

If Signal, the service, was designed to minimize metadata collection, then why is it so insistent on verifying each user's connection to an E.164 telephone number at registration? Even now, when we have usernames, they require us to prove a phone number which they pinky-swear they won't tell anyone. Necessary privacy tradeoff for spam prevention, they say. This isn't metadata minimization, and telephone number is a uniquely compromising piece of metadata for all but the most paranoid of users who use unique burner numbers for everything.

This is the most-frequently-asked question about Signal, it has a clear answer, the answer is privacy-preserving, and you can read it over and over and over again by typing "Signal" into the search bar at the bottom of this page.

The answer is not privacy-preserving for any sense of the word "privacy" that includes non-disclosure of a user's phone number as a legitimate privacy interest. Your threat model is valid for you, but it is not universal.

The question you posed, how Signal's identifier system minimizes metadata, has a clear answer. I'm not interested in comparative threat modeling, but rather addressing the specific objection you raised. I believe we've now disposed of it.

I don't believe there has been any such disposition in this thread. There have been vague assertions that it's been asked and answered elsewhere. Meanwhile, the Signal source code, and experience with the software, clearly demonstrates that a phone number is required to be proven for registration, and is persisted server-side for anti-spam, account recovery, and (as of a few months ago, optional) contact discovery purposes.

Yes. There's also libraries that do this, like libsignal.

It’s not practically open source though - how many people actually build it themselves and sideload onto their Android/iphone?

How much effort would it be for the US government to force Google to ship a different APK from everyone else to a single individual?

I don't know, a lot? They could with the same amount of effort just get Google to ship a backdoored operating system. Or the chipset manufacturer to embed a hardware vulnerability.

"Here's a court order, you must serve this tainted APK we built to the user at this email"

"You must backdoor the operating system used on billions of devices. Nobody can know about it but we somehow made it a law that you must obey."

Come on, that's not the same amount of efforts at all.

Looks like exactly the same amount of effort to me?

Effort maybe but not likelihood of discovery

The cryptography is not where Signal is vulnerable. What Signal is running on, as in operating system and/or hardware that runs other embedded software on "hidden cores", is how the private keys can be taken.

Anything you can buy retail will for sure fuck you the user over.

Retail hardware actually has a better track record at the moment than bespoke, closed market devices. ANOM was a trap and most closed encryption schemes are hideously buggy. You're actually better off with Android and signal. If we had open baseband it would be better, but we don't, so it's not.

Perfect security isn't possible. See "reflections on trusting trust".

Bespoke but-not-really-bespoke closed-market devices made by the right people are very secure, but they are not sold to the profane (you).

> ANOM was a trap

Yes, ANOM was intended to be a trap.

> and most closed encryption schemes are hideously buggy

Yes they are. Hence some of us use open encryption schemes on our closed-market devices.

> You're actually better off with Android and signal.

I am better off with closed-market devices than I am with any retail device.

> If we had open baseband it would be better

And the ability to audit what is loaded on the handset, and the ability to reflash, etc. In the real-world all we have so far is punting this problem over to another compute board.

> Perfect security isn't possible.

Perhaps, but I was not after "perfect security", I was just after "security" and no retail device will ever give me that, but a closed-market device already has.

> See "reflections on trusting trust".

Already saw it. You're welcome to see:

  - https://guix.gnu.org/blog/2020/reproducible-computations-with-guix/
  - https://reproducible-builds.org
  - https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/

Oh, so none of this has anything to do with Signal. Ok!

In theory, "none of this has anything to do with Signal", and you are correct ; but back over here in reality: Signal runs on these systems.

Hence the security afforded by Signal is very weak in-practice and questionable at best.

> Unfortunately there is no practical way to verify it either.

discuss an exceedingly clear assassination plot against the President exclusively over signal with yourself between a phone that's traceable back to you, and a burner that isn't. if the secret service pays you a visit, and that's the only way they could have come by it, then you have you answer.

I think the bar for paying such a visit would be infinitely high (they would find a way to defend in a more clandestine manner) to keep the ruse going.

Let us know how that goes

Signal's servers have access to your profile, settings, contacts, and block list if the PIN you select has low security.

Which is to say: in the worst-case plausible failure model for Signal, they get the same metadata access as all the other messengers do. OK!

Not all other messengers require a mobile phone number in order to get access, meaning not all other messengers have a view of users' social networks - some of them are anonymous, and Signal is not. It's a fundamental difference. But we've been here before.

They kill people based on metadata - they told us so. They don't need the rest.

Threema leaks no such metadata

https://breakingthe3ma.app/

You want to use this, by all means.

Were any/all of those vulnerabilities mitigated?

Per the link. Yes. Here the specific statement.

Lessons Learned

We believe that all of the vulnerabilities we discovered have been mitigated by Threema's recent patches. This means that, at this time, the security issues we found no longer pose any threat to Threema customers, including OnPrem instances that have been kept up-to-date. On the other hand, some of the vulnerabilities we discovered may have been present in Threema for a long time.

For what it's worth, and obviously I could have been clearer about this: what's interesting about that link is the description of Threema's design, not the specific vulnerabilities the team found.

While the statments are contradictory I wouldn't take it as sign of some vast conspiracy. I would just take it as a sign they are stuck needing to give out some kind of guidance to prevent foreign access. While they are a domestic police service they are also a counterintelligence service and thus need to provide some guidance there.

Telcos need a way to comply with court orders. That's it.

No, the feds require CALEA-backdoors. Absent CALEA, a telecom could say we don't have the data or the capability

US Military has atleast privately switched away from any Signal usage within the past few months – it’s undoubtedly compromised in some way. If the FBI is recommending it it’s for exploitative purposes & a false premise of safety.

So what’s the alternative

Completely avoiding sensitive communication over mobile phones.

Session, Matrix, Tox perhaps

I know nothing about this field so I went looking for those product names.

I believe the Session referred to is here ... https://getsession.org/

Tox is here ? https://tox.chat/

The Matrix i found seems to have been closed down earlier this month ... https://en.m.wikipedia.org/wiki/Matrix_(app) ... that's assuming I found the correct "matrix".

If it matters to you don't take my word for those being the correct points of contact, that's just me searching for two minutes.

As a side rant, I wish people would choose less generic names for their projects, calling something "session" ? You might as well call it "thing".

This is probably the Matrix they meant: https://matrix.org/

Thanks, that does seem more plausible than the one I found.

SimpleX?

Reply on news.ycombinator.com