While I will definitely agree that Signal is more secure:
There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES. Beeper implements it, I never got around to backporting it to pypush proper.
Also, the new Contact Key Verification (I believe it is the same thing as "key transparency" internally) should prevent the man-in-the-middle.
A lot of the things you mentioned can actually be solved on the pypush side: there's nothing preventing pypush from alerting you when a new key is inserted, or providing you with the fingerprints of each of the keys.
I'm not an expert on these things, but I do think it is time that another analysis by a proper cryptographer was done: the one you linked was from 2015, and a lot has changed since then.
Anyway, the point of iMessage is convenience, if we're being honest here. It provides a reasonable level of security that will keep out all but the most entrenched and determined attackers, and that's really all most people care about.
If third party client has optional E2EE, it's not exactly a merit to Apple, aside perhaps them not explicitly blocking such development.
I commented on the key verification in the other reply, it appears to be opt-in feature, so warnings about key changes are similar to WhatsApp, available if you known about them and you know you need them.
>A lot of the things you mentioned can actually be solved on the pypush side:
Yeah a lot of the problems can usually be fixed by fixing them. :) "At least it's not fundamentally borked" can't be the standard for a multi-trillion dollar company.
>a lot has changed since then
That's just the sad part. 1280-bit keys are still there. RSA is still there. Fingerprints were added but they're opt-in.
Apple can afford to hire Moxie or OWS to implement Signal protocol for them. The fact they treat iMessage as a second class SW in their otherwise high security is ridiculous. People deserve better and they should demand better.
>It provides a reasonable level of security
But that's just it. RSA isn't reasonable. Forward secrecy became the reasonable expectation in new protocols in 2004. It was 'This Love' by 'Maroon 5' years ago. TLS1.3 has already killed RSA entirely. 1280-bit keys haven't weren't acceptable even then. OTR from 2004 used 1536-bit RSA.
If people knew it was borderline ancient in terms of it's technology, they probably wouldn't find the unnecessary risks convenient.
My point is: Apple can afford an overhaul, and they damn well should rewrite the protocol.
> There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES.
Does that scheme definitely use ephemeral keys? Do you know if there is any documentation on it available?
> Beeper implements it, I never got around to backporting it to pypush proper.
Ah, thank you, this is important context! I looked through pypush and couldn't find anything that looks like it might be providing forward secrecy, so I was wondering if that was a misunderstanding of the impact of (only) switching to ECIES, as forward secrecy would require more than that.
There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES. Beeper implements it, I never got around to backporting it to pypush proper.
Also, the new Contact Key Verification (I believe it is the same thing as "key transparency" internally) should prevent the man-in-the-middle.
A lot of the things you mentioned can actually be solved on the pypush side: there's nothing preventing pypush from alerting you when a new key is inserted, or providing you with the fingerprints of each of the keys.
I'm not an expert on these things, but I do think it is time that another analysis by a proper cryptographer was done: the one you linked was from 2015, and a lot has changed since then.
Anyway, the point of iMessage is convenience, if we're being honest here. It provides a reasonable level of security that will keep out all but the most entrenched and determined attackers, and that's really all most people care about.