Recent searches
Search options
@contrapunctus@en.osm.townPosting and pinning this because Soatok's misinformation has infected far too many. *Everyone* needs to read this in its entirety, *especially* all the #Signal Kool-Aid drinkers.
https://www.moparisthebest.com/against-silos-signal/
*And* the response from OMEMO author Tim Henke, which Soatok saw fit to redact from their post comments.
https://www.moparisthebest.com/tim-henkes-omemo-response.txt
Ooof. The first sentence already implies behaviour that is simply not true.
Yes, they can update when they want, but signals android build is reproducible. You can verify what you get with each update. That doesn't mean that they cant try to backdoor signal, just that they will be immediately spotted.
A supply-chain attack like this is something everyone has to deal with, *including* xmpp.
@newhinton @contrapunctus
1. Not everyone can verify this reproducibility. Google and Apple can deliver modified versions of the app to targeted users.
2. Even after reproducing, you only verified that you included the same proprietary code that loads and executes more proprietary code from a third party.
Rather than @signalapp, we should advertise @mollyim FOSS (not the GMS version) much more, which is a more secure client, but connecting to the same server.
@pixelschubsi @contrapunctus @signalapp @mollyim
1. Yeah that's true. (In fact, i dont do it either) But it is also not that important, because in general you dont need everyone to verify this. You just need *enough* people to do it, so that shenanigangs would immediately be flagged. (And the shitstorm would be massive if they tried that)
2. What proprietary code? (afaik the non-play apk should not contain any, and the important bits are all open source even in the play version)
@newhinton @contrapunctus
1. No, you need not "enough" people to do it (whatever that means), but you need at least one of the targeted people to do it. Assuming a clever attacker, they will not target people which they deem capable of verifying the downloaded binary.
2. The website version is largely the same as the Play Store version, they did remove the in-app-billing part, but not other proprietary Google libraries. Molly FOSS had to do additional work to also get rid of those.
Yeah but that's the point. If you are a state actor, then you probably have an extremely different threat-profile than most people. And to protect *most* people, it is enough to verify the general reproducibility. The rest is taken care of by the android security model.
You can't target "just" people who don't check the apk for malicious changes, thats out of your control (as an attacker). It takes just one person to find those to create a massive global outcry.
@newhinton @contrapunctus
Only if your attacker is not able to control Apple/Google to some degree (either through administrative power or by attacking them first). For example, Google already has logic to deliver different apk to selected users (the beta testing feature), which could be easily adjusted for this purpose.
Signal claims to be safe enough for Snowden-level targets to use it. Snowden might have been able to spot this, but not everyone Snowden-level is also Snowden-technical.
@pixelschubsi @contrapunctus True!
But then again, that is not a signal problem, but a repository problem. It also applies to any other app delivered by google, including eg. xmpp clients.
If that is your threat model, you need to find someone who can support you on that level anyway.
Or you get your own build, or the apk from signal's webpage, or as you suggested, molly. And then all the other guarantees of signal's security apply again, making it a secure messenger.
@newhinton @contrapunctus
Molly FOSS is available on their F-Droid repository. You thus don't need to trust Google. While Molly could of course also try to distribute malicious versions, they can't target identify and thus target individual users, because repository access is not authenticated.
@newhinton @contrapunctus
2 cont: The play services maps library includes code to dynamically load code from Google at runtime and execute it with the same privileges as the "relevant" code. Thus, Google can modify the executed code to upload all messages without the need to break the reproducibility of the apk file.
@newhinton @contrapunctus the key element of that sentence is: "all ends", including the (centralized, non-reproducible) server, which might not decrypt the message contents but may introduce enough harmful shenanigans
Signal is designed to protect it's users against the server behaving maliciously. That's the *whole* point.
It doesn't matter if the server is compromised, maliciously changed, seized or otherwise a bad actor, because the cryptographic design *ensures* that the server doesn't have anything worthwhile.
@newhinton @contrapunctus metadata *are* worthwile
Yes, but signal's server *does not have* metadata. That is their whole mission, write an e2e-messenger that reduces metadata-creation where possible. And they are quite successful at it.
(In comparison to most alternatives, like matrix or xmpp which store a lot of metadata on their respective instances, or sometimes even on multiple third-party servers in the case of deltachat)
@newhinton @dan @contrapunctus please link a paper or statement from signal that claims that it doesn't matter if the signal server is malicious. As far as I know, Signal arranges encryption and identity keys, sees recipient addresses for messages, let's Cloudflare see IP addresses of each signal group etc. It's one thing to cheer on signals groundbreaking cryptography but I am afraid you are vastly overstating the case.
What do you mean by "arranges" Keys? The clients, yes, but the server isn't involved besides arranging "meetup" of clients.
Keys are determined exclusively by the clients and don't leave them. (e2e)
https://signal.org/docs/ has a list of documents explaining how the protocols work, and links to the used implementations.
Yes, it sees recipents, but not senders, so the server cannot establish a relationship between them.
For the ip's to matter, you need to also 1/2
@hpk @dan @contrapunctus
compromise the isp's that manage those, and only then you *might* be able to map it to a user. But then again this is something only state actors can do, and they have way easier ways to get your data.
(Also, it is comparatively easy for you to protect yourself against that by using tor/proxies etc if that is your threat-model)
@newhinton @hpk @contrapunctus that‘s exactly the threat model the Snowden leaks showed. ISPs *are* compromised and metadata (IPs etc) are usually more interesting to state actors than the content. Way easier to get with one central server and already compromised ISPs
Sure!
But there is not a whole lot of metadata available to them. They'd know that you are using signal, and that you just send a message. That's it.
(For comparison, many other messers produde *a lot more* publicly available metadata. That's the point: signal doesn't prevent *all* metadata creation, but out of the messengers available, by far the least.)
Many decentralized services don't even try to minimize this creation at all.
@dan @hpk @contrapunctus
Oh, and i said 'they know you send a message'.
That was a misnomer, they know that an ip used signal. They *don't* know if it was *you*, or your neighbour, or a guest using your wifi.
At that point it is probably more reliable to guess which message belongs to wich recipent, even if you infiltrated the isp.
@newhinton @hpk @contrapunctus nah, most devices end up leaving a wifi and you get the IP of a mobile ISP which you can pinpoint to a distinct customer
@newhinton @hpk @contrapunctus
With a centralized service you only need to control that one service (and the ISPs) to get relevant metadata. With decentralized ones you need to control more ends, which gets even more difficult if your target self-hosts a service
If you are worried about state actors infiltrating, and taking over both all isp's you might use, and all of signal's servers to get a tenous social graph at best, do you really think it will be any kind of effort to break into either any selfhosted service or a vps?
1/2
The fact is: signal is world class at preventing metadata creation, and no other app comes even close.
In addition to that, there are issues with signal, but those are inherent to the internet, and apply to all other apps (decentralized or not), usually worse when they don't minimize metadata collection.
For signal atleast, those internet-inherent issues can be worked around (tor, etc). But the collected metadata on any xmpp server is just there for the grabs. 2/2
@newhinton @dan @contrapunctus signal arranges for encryption keys ... It sits in the middle of a DH exchange. It also is responsible for binding an identity key to a phone number. There have been studies like "when signal hits the fan" that people eg fail to notice compromise through mitm attacks. But if you find a signal statement or a researcher who claim what you claim (signal server can be malicious, it still is safe for users) please link it and not some general.dpcumentation. thanks.
I am well aware that signal sits in the middle of the DH exchange.
Which does not matter, since that is exactly what diffie hellman was created for. The server *cannot* interfere with that. (x3dh, 4.8)
Claiming that signal "arranges" the private key material is outright wrong.
The identity key does not leave your clients device. This is not how public-key cryptpgraphy works. Signal likely maps your publickey to your phonenumber, but not the private key. (And if you claim so, you need to provide proof, same for the mitm statement)
I have provided a primary source for both general overview over the protocol, and implementation details of the used library. The rest is up to you.
@newhinton @dan @contrapunctus I said arranges encryption key, not decryption keys. So I am not sure why you are claiming that I said "arranges private key", sorry
I am aware of what you said.
And again, signal does not arrange the keys. The keys which are send to signals servers are client-generated publickeys. (In your terms: encryption keys)
Those are *meant* to be send over insecure channs. You can't tamper with them. If you do, your crypto doesn't work. If you man-in-the-middle the exchange, your safetynumbers dont match.
There is no way to break this and secretly get away with it, regardless how hard the server tries.
No, Signal knows what ip linked to what account and phone number sends a message to what other account linked to what ip and phone number and voluntarily discards that information. It's nice, but it's not something that can be physically enforced while entrusting a single entity with everything
That is factually wrong. Signal does not store the message-sender. That is part of the encrypted content.
Signal-the-app does not *store* metadata, but at some point signal-the-server *knows* about it and voluntarily discards it. That's what the initial post is about: it decides what it does, and can make the unilateral position to change it.
@contrapunctus @dan
@newhinton @contrapunctus no ok, let's assume you've spotted this. Or even more stupid - the US govt shuts Signal down. What to do next?
That is a different question. The original article stated that signal's security was somehow problematic. Which it is demonstrably not. (if you spot some malicious changes, you'd obviously need to immediately stop using it, and talk to people who know how to deal with that. news, comp-sec people, etc)
But mostly what you are referring to is availability, and in that case there are a few things signal isn't great at, and they don't claim to be. But thats a different topic