Hopefully they can dodge RCS too, because it’s a poor solution. Worse, Apple’s implementation of RCS doesn’t include E2E encryption.
Edit: RCS limits attaments to 100mb! What the hell, why? I can, today, send 100mb over SMS/MMS, on Verizon, to other Verizon phones. RCS would be a step backward.
I don’t really care about iMessage, Android is my primary device, and SMS sucks, and most people use SMS because Android, and I prefer to use other apps (especially on my iOS devices).
IMessage has its own insecurities, despite what people think. There’s a recent publication about it while it uses AES to encrypt the message, the encrypted message and the AES key are packaged together with the RSA key…which never changes. So if you get someone’s RSA key, you can decrypt all their messages, old ones, new ones, ALL of them.
So if they can dodge it, this keeps the pressure toward third-party apps with proper encryption, that isn’t tied to your IMEI, Google or Apple accounts.
And this is what governments fear the most - they peoe will use apps like Signal, where not even the metadata is easily accessible or useful even if you could access it.
After 3 months of using RCS with Jibe, I have decided to turn RCS off due to it’s instability, unreliability, and lack of standardization. Sometimes, I’d send an RCS message and it wouldn’t go through, and sometimes someone would send me a message via RCS, and I wouldn’t get it.
In some RCS group chats, I would only see half the conversation because some people would send messages in the group chat, and I wouldn’t get them. You know what, I could list off RCS problems for 48 hours without stopping, but that would be a waist of time. The point is RCS is buggy, and doesn’t work. The Cross Carrier Messaging Initiative already failed, so there is absolutely no way RCS will ever be able to replace SMS. This, along with RCS’s bugs, is the reason why RCS will only be good enough to be a broken and unreliable iMessage for Android. Without the carriers, there is no way RCS will ever become a standard, and I don’t think Apple will ever adopt RCS because of the stupid decisions of carriers, Google, and smartphone manufacturers.
The whole reason I started using RCS was because I wanted to support it, not because I actually liked it. Now, there is no reason to support RCS because it is a broken messaging system, and will never become a standard. Android is extremely fragmented, and it will continue to be fragmented for a very, very long time
A 100MB file transfer over MMS? I’m not saying you’re lying, but recognize that is highly abnormal and most carriers aren’t going to support anything near that high. 100MB would be a huge upgrade for most people over MMS.
I have no idea what carrier this user is with and I agree that sounds absurd. Photos and videos are automatically downgraded before being delivered. The file size limit is typically below 5MB. Videos are like 480p and photos are 720p. I hate sending photos through MMS and would rather use data with a different messaging app if RCS isnt available.
There is no such specification. It is solely up to the provider. For example, T-Mobile and ATT both state 100MB on their “Advanced Messaging” FAQ. I’m sure Verizon is the same though I couldn’t find the exact wording.
Photos and Videos through RCS use your data.
The spec does state there is an 8,000 character limit and a maximum of 100 participants in a group conversation.
I commented further down, but I think you are confused with this bit:
RCS limits attaments to 100mb! What the hell, why? I can, today, send 100mb over SMS/MMS, on Verizon, to other Verizon phones. RCS would be a step backward.
The maximum file size for picture/video messages depends upon the device software and device’s network capability. View the signal indicator on your phone to determine which signal is being received:
Yeah, it sounds good but there’s a lot of factually incorrect statements.
“Apple RCS” is actually the GSMA RCS standard, which Apple was pretty vocal about not being encrypted, but was kind of forced to use prematurely thanks to legislation. Encryption is already being looked at being added in the next spec.
The user’s outgoing message is individually encrypted for each of the receiver’s devices. The public encryption keys and signing keys of the receiving devices are retrieved from IDS. For each receiving device, the sending device generates a random 88-bit value and uses it as an HMAC-SHA256 key to construct a 40-bit value derived from the sender and receiver public key and the plaintext. The concatenation of the 88-bit and 40-bit values makes a 128-bit key, which encrypts the message with it using AES in Counter (CTR) Mode. The 40-bit value is used by the receiver side to verify the integrity of the decrypted plaintext. This per-message AES key is encrypted using RSA-OAEP to the public key of the receiving device. The combination of the encrypted message text and the encrypted message key is then hashed with SHA-1, and the hash is signed with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the sending device’s private signing key. In iOS 13 or later and iPadOS 13.1 or later, devices may use an Elliptic Curve Integrated Encryption Scheme (ECIES) encryption instead of RSA encryption.
The resulting messages, one for each receiving device, consist of the encrypted message text, the encrypted message key, and the sender’s digital signature. They are then dispatched to the APNs for delivery. Metadata, such as the timestamp and APNs routing information, isn’t encrypted. Communication with APNs is encrypted using a forward-secret TLS channel.
In short: The per message AES key is derived from the contacts public RSA key.
Erm that’s not how it actually works. Though in your defence, “in short” is pretty hard to achieve here.
The real headache though isn’t encrypting the messages. It’s making sure that only the intended recipient has the decryption key for your message. That’s where E2EE messaging gets complex and frankly Apple doesn’t do the best job.
It’s theoretically possible with iMessage, especially in a nation state level attack, for a compromised device to be one of the recipients your encrypted message is sent to. Wether “theoretically” is “actually in practice” happening is hard to judge, because nation state attacks are normally hidden by court mandated disclosure suppression orders.
The way Signal is architected, it wouldn’t be possible to comply with a court order like that. Unfortunately that means some Signal based messaging services will be forced to exit the UK since laws coming into effect next year will give them no other choice. It’ll be interesting to see if signal based services (like Google RCS) also walk or will they weaken their encryption in order to be able to comply.
The fact at least one nation state is passing laws that force “encrypted” messaging services to have the vulnerability that iMessage has is a pretty strong smoke signal that attacks like that are happening…
Erm that’s not how it actually works. Though in your defence, “in short” is pretty hard to achieve here.
That’s why I attached the entire quote and linked to Apple’s support doc just below what I over-simplified.
But I will say the rest of what you wrote is a pretty decent insight. Thanks.
Kind of a mixed bag.
Hopefully they can dodge RCS too, because it’s a poor solution. Worse, Apple’s implementation of RCS doesn’t include E2E encryption.
Edit: RCS limits attaments to 100mb! What the hell, why? I can, today, send 100mb over SMS/MMS, on Verizon, to other Verizon phones. RCS would be a step backward.
I don’t really care about iMessage, Android is my primary device, and SMS sucks, and most people use SMS because Android, and I prefer to use other apps (especially on my iOS devices).
IMessage has its own insecurities, despite what people think. There’s a recent publication about it while it uses AES to encrypt the message, the encrypted message and the AES key are packaged together with the RSA key…which never changes. So if you get someone’s RSA key, you can decrypt all their messages, old ones, new ones, ALL of them.
So if they can dodge it, this keeps the pressure toward third-party apps with proper encryption, that isn’t tied to your IMEI, Google or Apple accounts.
And this is what governments fear the most - they peoe will use apps like Signal, where not even the metadata is easily accessible or useful even if you could access it.
Here’s just one well written example of what’s wrong with RCS: https://www.reddit.com/r/UniversalProfile/comments/11b6fyd/ugh_rcs_really_does_stink/
The text of that post:
A 100MB file transfer over MMS? I’m not saying you’re lying, but recognize that is highly abnormal and most carriers aren’t going to support anything near that high. 100MB would be a huge upgrade for most people over MMS.
I have no idea what carrier this user is with and I agree that sounds absurd. Photos and videos are automatically downgraded before being delivered. The file size limit is typically below 5MB. Videos are like 480p and photos are 720p. I hate sending photos through MMS and would rather use data with a different messaging app if RCS isnt available.
“Verizon Messages” is RCS.
deleted
Perhaps the the EU should be looking at a forced divestment of Jibe?
Does it say so in the specification or is that the limit of a single RCS provider? How does sending files even work in RCS?
There is no such specification. It is solely up to the provider. For example, T-Mobile and ATT both state 100MB on their “Advanced Messaging” FAQ. I’m sure Verizon is the same though I couldn’t find the exact wording.
Photos and Videos through RCS use your data.
The spec does state there is an 8,000 character limit and a maximum of 100 participants in a group conversation.
I commented further down, but I think you are confused with this bit:
This is not true by any means. See here: https://www.verizon.com/support/knowledge-base-14641/
deleted
That’s a proper comment right there
Yeah, it sounds good but there’s a lot of factually incorrect statements.
“Apple RCS” is actually the GSMA RCS standard, which Apple was pretty vocal about not being encrypted, but was kind of forced to use prematurely thanks to legislation. Encryption is already being looked at being added in the next spec.
How Apple encrypts iMessages is literally detailed in their support doc. In short: The per message AES key is derived from the contacts public RSA key.
Erm that’s not how it actually works. Though in your defence, “in short” is pretty hard to achieve here.
The real headache though isn’t encrypting the messages. It’s making sure that only the intended recipient has the decryption key for your message. That’s where E2EE messaging gets complex and frankly Apple doesn’t do the best job.
It’s theoretically possible with iMessage, especially in a nation state level attack, for a compromised device to be one of the recipients your encrypted message is sent to. Wether “theoretically” is “actually in practice” happening is hard to judge, because nation state attacks are normally hidden by court mandated disclosure suppression orders.
The way Signal is architected, it wouldn’t be possible to comply with a court order like that. Unfortunately that means some Signal based messaging services will be forced to exit the UK since laws coming into effect next year will give them no other choice. It’ll be interesting to see if signal based services (like Google RCS) also walk or will they weaken their encryption in order to be able to comply.
The fact at least one nation state is passing laws that force “encrypted” messaging services to have the vulnerability that iMessage has is a pretty strong smoke signal that attacks like that are happening…
But I will say the rest of what you wrote is a pretty decent insight. Thanks.