Viewing a single comment thread. View all comments

uwu2420 t1_j9y3ix1 wrote

The thing you’re missing is, if you’re using Signal you specifically want an end to end encrypted chat service.

The OS doesn’t upload that data in unencrypted form. You can analyze for yourself with a MITM proxy.

iMessage is secure, as long as you don’t care for your messages remaining end to end encrypted, and you trust Apple to have a copy of your messages. Is that reasonable to you? Maybe, maybe not.

With Signal, the whole idea is you shouldn’t have to trust Signal with your messages, because they don’t have the ability to read them, even if they wanted to. Yes, it could have holes like any software, so this can really be simplified to: use the tool with a known issue for sure, vs use the tool that might have an issue in the future but for now is known to be safe.

1

drawkbox t1_j9y44d1 wrote

> end to end encrypted chat service

End to end means nothing though when a client isn't in your control and may have another user attached. Again, common in many messaging apps.

iMessage is end to end encryption to iMessage, just like Signal to Signal. If you use SMS it is not.

> We designed iMessage to use end-to-end encryption, so there's no way for Apple to decrypt the content of your conversations when they are in transit between devices. Attachments you send over iMessage (such as photos or videos) are encrypted so that no one but the sender and receiver(s) can access them

Apple can't magically make SMS secure, it is not secure by default as it was really from telephone diagnostics and repurposed for messaging. So when you message Android it goes SMS. SMS was from SS7 and really only for diagnostic or messages to customers for testing. MMS is better but still not that great. Apple should bring iMessage to Android and do better on messengers, it is leading many people to third parties that open up opsec issues.

> With Signal, the whole idea is you shouldn’t have to trust Signal with your messages, because they don’t have the ability to read them, even if they wanted to.

That is a bold statement. Yes, on the surface. Again, ghost users, compromised clients, endpoints can have problems. Also Signal does have a proprietary shim for monitoring, spam checking and other things, could easily be used to surveil or sift. There are probably a dozen ways or more to get around it currently at the dependency level or breaking their encryption as it is custom.

The best opsec is always less third parties.

−1

uwu2420 t1_j9y4q7s wrote

We can assume the majority of people go with the default settings. iMessage conversations, by default, end up in a backup file on iCloud that is not end to end encrypted. Signal conversations, by default, do not.

> We designed iMessage to use end-to-end encryption

Which again is worthless when a plaintext version is also being uploaded in the form of iCloud backups, which are on by default. The same isn’t true for Signal.

You’ll have to provide a source for your claims about Signal’s ghost users. As far as a compromised client, that’s not something any messaging client can defend against, and if a service is end to end encrypted, it shouldn’t matter if the endpoint server is entirely compromised.

> breaking their encryption as it is custom

That’s the cool part, it’s not. It’s based on the same old algorithms that have been around for years. ECDSA, ECDH, AES, etc. if I remember correctly

It depends on your definition of opsec but just a reminder that we’re in a thread about Signal and end to end encryption specifically.

2

drawkbox t1_j9y5gri wrote

You dismiss user level auth/encryption like it is nothing. If anyone had access to user level auth why go to the backup file, just go to the device, load up Signal and scrape their messages.

All other messaging apps have the "ghost user" problem confirmed.

Signal has a shim for spam that is very unclear, I'll just say that. There are other things around Signal that make is sus in my opinion.

> The source code for spam detection is not public.

So there is a plausible deniability reason to hide some code... you have to trussssst. Here's the kicker, you can't check for spam if you aren't seeing the message.

Even on the self installed versions...

> Signal's servers are partially open source, but the server software's anti-spam component is proprietary and closed source due to security concerns

Signal does handle users being added better, but this could just be theater as well.

> The real problem with the GCHQ proposal is that it targets a weakness in messaging/calling systems that’s already well-known to providers, and moreover, a weakness that providers have been working to close — perhaps because they’re worried that someone just like GCHQ (or probably, much worse) will try to exploit it. By making this proposal, the folks at GCHQ have virtually guaranteed that those providers will move much, much faster on this.

> And they have quite a few options at their disposal. Over the past several years researchers have proposed several designs that offer transparency to users regarding which keys they’re obtaining from a provider’s identity service. These systems operate by having the identity service commit to the keys that are associated with individual users, such that it’s very hard for the provider to change a user’s keys (or to add a device) without everyone in the world noticing.

> As mentioned above, advanced messengers like Signal have “submerged” the group chat management into the encrypted communications flow, so that the server cannot add new users without the digitally authenticated approval of one of the existing participants. This design, if ported to in more popular services like WhatsApp, would seem to kill the GCHQ proposal dead.

I personally don't trust Signal for a few reasons beyond these items, but if you trust them then rock on.

−2

uwu2420 t1_j9y65ub wrote

> You dismiss user level auth

To scrape my Signal messages, you need access to my physical device, and you need my passcode. To get access to iMessage messages, all you need to do is get my latest backup, or the backup of the person I talked to, off of Apple’s servers, for example, with a legal request, which completely bypasses the need for any user level auth/encryption.

Agree to disagree

2

drawkbox t1_j9y8ajk wrote

> To scrape my Signal messages, you need access to my physical device, and you need my passcode.

Same with getting access to your iCloud/Apple account.

> To get access to iMessage messages, all you need to do is get my latest backup, or the backup of the person I talked to, off of Apple’s servers, for example, with a legal request, which completely bypasses the need for any user level auth/encryption.

As I said, anything stored in a cloud will have some oversight. Anyone that thinks storing something in a cloud is secure from oversight is dim.

If you think anyone from enforcement can just get your iCloud/Apple account, that would also mean they are able to access your device and everything on it including your "encrypted end to end" Signal messages that are plaintext on your client.

Messaging apps also get cam/mic/location/contacts permissions, Signal is no different, one more entity with your face/voice/place/friends.

You can trust Signal, a third party, rock on. Acton is involved in both, from WhatsApp, went to Facebook, and then when people stopped trusting Facebook he made Signal to catch those leaving. The story is he didn't trust Facebook, no one should, but can you trust Signal/Acton or is it a front. You decide. Problem is you trust them so much they got ya. I mean Elon Musk and Edward Snowden recommend it... is must be safe /s. Signal is maybe safe, maybe safe from some five eyes, but not all eyes not in the five. Even then, there are always ways to get in via dependencies and devs (mainly devops) are the weak link today sadly.

Agree to disagree, good discussion though.

0

uwu2420 t1_j9y8y3c wrote

> Same with getting access to your iCloud/Apple account

No you don’t, because it is stored unencrypted on Apple servers and Apple themselves will give it to you (for example, with a legal request). If you go this route, you don’t need the physical device or any of the user’s passwords. The user won’t even know it’s happened until they are told.

The difference is in one case, my password and my physical device is needed. If you want that, you’ll have to physically get my device from me, and then get me to tell you my passcode. The other is just stored on Apple’s servers. If you don’t see how one is much harder than the other, I dunno what to tell you lol

Edit: no need to believe me, believe American law enforcement instead and refer to the leaked slide I posted earlier.

2