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

> 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

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.

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.

Yeah I agree there are always vulnerabilities in software, but the thing is, as far as I know, there aren’t any known bugs that would leak data from Signal so far despite all the security research attention it gets, and plenty of evidence that it’s safe.

Meanwhile, I’ve already explained how it’s trivial to get around the end to end nature of iMessage for a large majority of users.

If you don’t care about your conversation being end to end encrypted, then yes, by all means, use iMessage or even just plain SMS. Much easier. But if you do care, I’m not sure why you’d shoot yourself in the foot with the option known to have a major workaround.

> I mean pretty much anything in a cloud should be considered secure from everything but law enforcement

Again, nope. If a cloud service is truly end to end encrypted, and designed well, nobody but the end user should be able to access the data. Yes, even if there is a subpoena.

> The point is your still need the user context

Or if you have access to the files on Apple’s server, then no user auth is required.

> These files only work with the OS to access them

Again, no. There are many commercial and open source tools that are able to read the backup file for you. Elcomsoft, iMazing and the Citizen Lab Mobile Verification Toolkit are some examples.

> Most people are worried about hackers

It wouldn’t be the first time someone’s iCloud account was hacked into.

> there is a “ghost” user ability

Show me where in the Signal code there is this functionality. Again, it’s open source, so a honeypot would be quickly found. Also, if you’re worried about state level honeypots, note that retrieving an unencrypted iCloud backup is a lot easier.

> It is only plaintext in the context of the user…

…and anyone with access to the files on Apple’s servers, which aren’t only subpoenas but also hackers, governments that don’t respect human rights, etc. which is the whole point of having end to end encryption, even the service provider themselves should not have the ability to access the data on your account.

Do you not understand the point of end to end encryption? The whole point is that nobody, not even the service provider hosting the cloud service can access your data.

The backup files not being encrypted is the whole point though. What good is everything else being encrypted if you can just subpoena or get a copy of the backup where all of that stuff that was encrypted is in plaintext lol

> Phone backups also don’t have to go to iCloud

Yes, but it’s on by default, and the majority of users have it turned on. Advanced Data Protection means you’re giving up a lot of account recovery options so most users don’t have that on, plus it’s only ~3 months old.

> This all falls apart when a participant is added

Well.. then just don’t add participants you don’t trust to your group chats…

> Focusing on just encrypted backups

But it’s a big issue lol. See above and refer to the slides I linked in the earlier comment. Again, what good is the encryption if there’s an easily available plaintext version too?

> When it is bought out by private equity

Signal is open source and you can run your own server if you want.

No, iCloud backups up until a couple months ago were not end to end encrypted and it was explicitly used by governments as a backdoor to get around iMessage encryption. There’s a leaked law enforcement slide about it somewhere.

https://support.apple.com/en-us/HT202303

See under “data categories and encryption”, under “standard data protection” (which was the only option up until a couple months ago, and still the default option to this day), note how iCloud backups (including both the full contents of the device, and iMessages) are not end to end encrypted.

Telegram’s encryption is a homebuilt algorithm rather than a tried and true standard (never roll your own crypto…) and as you pointed out not on by default. So it was always inferior to Signal.

Signal by default doesn’t keep its data in device backups. You’d need to build a custom client to get it to do that. There’s no way to get Signal to not end-to-end encrypt it’s chats, it’s on by default and can’t be turned off.

Edit: some more links to back this up:

https://www.howtogeek.com/710509/apples-imessage-is-secure...-unless-you-have-icloud-enabled/

And the leaked slide as I mentioned earlier:

https://www.pcmag.com/news/fbi-document-shows-how-popular-secure-messaging-apps-stack-up

There’s two big issues with iMessage that Signal solves:

1. iMessage only works with iOS devices

2. iMessages are end to end encrypted, BUT, they are stored in readable format in iOS backups, and since most people tend to use iCloud backups, which by default are not end to end encrypted, this is used as a back door to defeat the protection. The option to encrypt iCloud backups, Advanced Data Protection, is new and only came out a couple months ago — prior to this, there was no way at all to encrypt iCloud backups. Importantly, as a sender, you have no idea if your recipient is taking the proper precautions, and no way to enforce it.

Do paternity tests give a certain yes or no now? I needed one for citizenship purposes years ago and the report we got only had a percentage, like, “there’s a 99.995% chance of paternity” or some very high but slightly under 100% percentage, but not a solid yes or no. They explained to us at the time that no test could be 100% certain, so a yes or no answer would be invalid.

I’m a reverse engineer (mostly as a hobby) so I welcome the challenge should I need that at some point. :)

Although… it’s well known in information security to not roll your own cryptography or to rely on security by obscurity. And in my experience, most proprietary 2FA apps do use some form of standard 2FA algorithm, they might just be using a proprietary way of sharing the 2FA secret, have undocumented APIs for rolling secrets, or are using lesser-known (but still, standardized) 2FA algorithms like HOTP, which are all reasonably easy to figure out for a determined enough developer.

If you have a profitable strategy, very profitable

If you have a shitty strategy, you’ll lose money faster.

If the 2FA is TOTP, then get a TOTP generator library

If the 2FA is SMS, set up a $3/mo number through Twilio.

What is the problem?