Comment by some_furry | Hacker News Reader

Comment by some_furry | Hacker News Reader

Parent Full thread

> With XMPP I can run (and audit) eveything myself.

You're saying this in response a blog post where I basically did an over-the-weekend audit of Signal's cryptography. I don't know if you understand the irony of that.

> Some proprietary messenger

It's literally GPL free and open source software

> that's hostile to 3rd party clients

I disagree with Moxie on his stance about XMPP + federation, as I wrote about here (relating to my plans to build E2EE for the Fediverse): https://soatok.blog/2024/08/28/introducing-alacrity-to-feder...

> aswell as also wanting my phone number

I dislike this as well, but since the introduction of usernames, it's at least no longer required to give strangers your phone number to converse with them.

> will never compete with tried and tested open source technology like XMPP.

The converse is true: XMPP+OMEMO do not qualify as a Signal competitor. I've outlined my reasoning in the linked post.

Until the entire ecosystem uses the latest version of the protocol, encryption is always on, and there is no plaintext fallback, XMPP is a poor solution for private communications.

> There is a reason military and government orgs use their own infrastructure.

Are you insisting that XMPP is "military grade encryption"?

You can't trust the server on Signal. Anything else, especially theoretical navel-gazing about plaintext fallbacks or make-believe audits of the client half of the system is inconsequential against the simple fact: You can't trust the server on Signal.

You don't have to. Reproducible builds, audited E2E and the other technical details combine to remove the need to trust the server for anything other than availability.

Anything else is uninformed navel-gazing about the risk without understanding the subject.

But the server on signal may store who communicates with whom. The most important information of all; and they can even connect that to phone numbers, so they've basically got everbody's real names.

You should take a closer look at Sealed Sender and the zkgroup stuff.

I've explained in another comment but, it effectively hides who's actually communicating with who.

Neither of those have anything to do with that kind of security. The preparation process for sealed sender looks very complicated and iffy, but maybe someone has checked that the protocol is secure-- I don't see any reason for such a complicated procedure, and I see such complicated procedures as something which can only be intended to hide insecurity, but let's assume it is.

You still have connect to them and deliver this to the signal servers. They'll have your IP and will know approximately where you are physically.

There is no way to make this kind of thing secure without some kind of remailer system and without many peer-to-peer connections.

Almost all proper anonymous remailers have been shut down. What remains, Tor for example, are insecure parodies of an anonymous remailer, and this is justified to the users as being for the sake of speed, but makes the system useless for anonymity. Even Mixminion is insecure if you can observe the full network, since you can count the packets received by the clients and there aren't dummy packets.

> The preparation process for sealed sender looks very complicated and iffy, but maybe someone has checked that the protocol is secure-- I don't see any reason for such a complicated procedure, and I see such complicated procedures as something which can only be intended to hide insecurity, but let's assume it is.

I did, in fact, check it when writing TFA.

> You still have connect to them and deliver this to the signal servers. They'll have your IP and will know approximately where you are physically.

Okay, let's actually think this through.

You have millions of people using Signal. When you send a message, the message is encrypted such that only the recipient can decrypt the envelope to verify if you're even permitted to send to them. The only thing the server gets is an encrypted envelope and some 96-bit random string that tells the server where to send the envelope.

This 96-bit random string is derived from your profile key (which is also encrypted and, at minimum, rotates every time you block someone).

Let's assume Signal's server has been maximally pwned by the NSA to slurp as much data and metadata as possible in the most malicious manner logically possible. In this thought experiment, they will now log things that the server currently does not because of a government-mandated implant.

In this scenario, the NSA will learn: someone from an IP address send an encrypted envelope to an unknown recipient.

Later, they will learn that another user (and their IP address) accessed the same envelope when downloading it from the Signal server.

You might be sitting there, rubbing your hands, thinking, "Wow, we sure got them." Except that there are millions of Signal users, many whom share IP addresses over time, and you can't even be reliably sure if a given Delivery Token maps to a targeted recipient.

Furthermore, you can't reliably distinguish between 1:1 messages and group messages, due to how groups are implemented (see: zkgroup).

> There is no way to make this kind of thing secure without some kind of remailer system and without many peer-to-peer connections.

When you say "make this kind of thing secure", are you talking about hiding IP addresses and phone numbers from Signal's servers? Or are you suggesting what Signal is already doing is not possible in the first place?

Cryptography isn't magic. It is comprehensible to mortals.

Yes. So they know the IP of the sender, and of the receiver, and they know the time, and they can contact the ISP and ask them who had these IP addresses at the given time and thus determine with certainty who communicated with whom.

We used a law in the EU requiring ISPs to keep track of this. It was determined to be illegal, so many ISPs probably don't store this information anymore, but I am sure that many do, and there can be other people-- maybe someone from another country that comes to your country gets jobs at ISPs to modify their software and make it do things he wants.

I don't know about this Salt Typhoon, but as I interpret it, there was an excellent secure system, and then people built some kind of front end on top of it so they could enter their orders into it, and then somebody compromised that front end and basically started getting all the data that the government could order to be gathered. I'm thinking that's going to include who has what IP.

I agree though, the complexity is maybe okay. It doesn't sound like a super terrible protocol or that involved. I suppose the description I saw of it felt more convoluted. At the same, I felt that the complexity of the presentation was hiding something, which I think might well be true-- it might even have been this simple fact that the central server still has every opportunity to determine who sends things to whom.

> they can contact the ISP and ask them who had these IP addresses at the given time and thus determine with certainty who communicated with whom.

Public WiFi.

> I don't know about this Salt Typhoon, but as I interpret it, there was an excellent secure system

Hahahaha no. There was never an excellent secure system. Look at the past decade or so of SS7 attacks.

Anyway, people can get IP addresses of phones, public Wifi still tells them where you were and it only takes on mistake of you connecting through your own phone for them to know certain.

This taken together means there's no security with regard to contacts if the server or the network is compromised.

There are excellent solutions to this: dummy messages and remailing. Without those no system can ensure that contact information is kept secret.

But Signal offers optional features so that it does not know the former; nor the latter (usernames, etc.) Re: former - as discussed there's sealed sender (iirc been quite some time since they released it), but also depending on how you mean it - situation may be less scary for you even if not using sealed sender.

> so they've basically got everbody's real names.

Based on the above as well as on the fact that having phone number does not by itself == real name PII / identity - claiming "so they've basically got everbody's real names" is not just overly dramatic but also patently false and disingenuous. :( I'm sure you did not mean to dissuade people, but c'mon. Generalising in such a way and then adding hyperbole does not help, imho.

Yeah, of course you have to ask the phone company, but if you need to use Signal as opposed, then you are already assuming an adversary that does more than just snoop on the public Wifi he offers.

Such an adversary can ask the phone company whose phone number a certain phone number is, and they will tell him.

> but if you need to use Signal as opposed, then you are already assuming an adversary that does more than just snoop on the public Wifi he offers.

No, not necessarily. In fact I'd claim that we should all use Signal so that usage of Signal would not imply any kind of user profile (would not rconstitute any kind of meaningful signal where one could infer what kind of user they are).

I do believe that there's a spectrum of users with a corresponding spectrum of appropriate threat models.

If my own threat model (that I felt I had to adopt) was particularly gnarly, I would (1) use Signal sandboxed / in a VM, tunnelling all traffic through Tor (e.g. Tor listens on socket exposed to VM so that there's no easy way to work around tunnel), and/or (2) if particularly gnarly - would set up pre-shared one time pads with counterparties where possible, and use them to authenticate further, perhaps encrypt further (maybe just encrypting a session key, to save most of OTP) - essentially definitely not deem Signal enough by itself.

Signal correctly focuses on privacy, not on anonymity. The wider your set of claims as to what kinds of properties (from the set of: privacy, anonymity, censorship-circumvention, etc.) you provide, the higher the probability you're going to screw up with one of these, I'd say. Better to combine several tools where possible if your needs require it.

> Are you insisting that XMPP is "military grade encryption"?

I don't think that's the fair implication there, and I'd also hope you'd pull out "military grade" as a red herring, as meaningless marketing speak and ignore it instead of trying to trap someone using it. (unless it was a primary point they made, critical to their position, clearly not the case here)

Reply on news.ycombinator.com