3 ms·

Why was RCS even designed with a none encrypted mode? I get that the original spec isn't exactly new, but it's also not so old that encryption, security or priv

Why was RCS even designed with a none encrypted mode? I get that the original spec isn't exactly new, but it's also not so old that encryption, security or privacy wasn't an issue.

nubinetwork 2y ago
I'm not sure about the case of RCS, but I've seen some instances of a none cipher being better for compression and deduplication, because the encryption messes with the data.
- hagbard_c 2y ago
  You'd normally compress the data before encrypting it as that makes the resulting cyphertext more resilient against cryptanalysis as well as reduces the amount of data which needs to be encrypted so this sounds like a bogus reason.
  - nubinetwork 2y ago
    It depends on what you're doing I guess... for storage it doesn't make sense, but for pushing a lot of data over a private pipe, why spend the resources adding a cipher?
  - jayd16 2y ago
    You'd have to compress every single message separately and then encrypt them. That's still a far cry from being able to compress across every message.
  - lxgr 2y ago
    That doesn't allow you to deduplicate across users, though – which of course is the entire point, or the network would be able to see who's forwarding which documents.
- dontlaugh 2y ago
  I assume some sort of multicast.
jeroenhd 2y ago
It's the evolution of SMS/MMS; development started 18 years ago, in 2007. The modern spec is based on that with a whole bunch of additional revisions for things like video calling and transferring money. It was designed long before major messenger apps had e2ee in the first place. Had it been designed with the security practices at the time, the protocol would've been ossified to the point of being practically insecure by today's standards. In a sense, the fact nobody cared about it until the spec was old enough to drive is actually good for users. The GSMA which designs RCS also serves the needs of government agencies that are tracking (international) criminals, so I bet there must have been some pretty strong opposition against E2EE in the official spec. Frankly, I'm surprised they're even putting it in the spec.
izacus 2y ago
Encryption and privacy isn't an issue for carriers, which were part of the standard body and operate SMS protocol even in 2025. You assume everyone has the same goals in mind :)
lxgr 2y ago
Phone calls aren't encrypted either, if you think about it [1]. There's a large expectation of the telecommunications industry to be able to perform legal interception, and providing end-to-end encryption out of the box might be seen as a direct violation of that requirement. [1] Except, somewhat incongruently, between Google Fi subscribers on some Android phones: https://support.google.com/fi/answer/11295314?hl=en https://support.google.com/fi/answer/11295314?hl=en – no idea how that came to be and how it even works! I suspect it just upgrades to a FaceTime-like VoIP call.

Why was RCS even designed with a none encrypted mode? I get that the original spec isn't exactly new, but it's also not so old that encryption, security or privacy wasn't an issue.

nubinetwork 2y ago

I'm not sure about the case of RCS, but I've seen some instances of a none cipher being better for compression and deduplication, because the encryption messes with the data.

hagbard_c 2y ago
You'd normally compress the data before encrypting it as that makes the resulting cyphertext more resilient against cryptanalysis as well as reduces the amount of data which needs to be encrypted so this sounds like a bogus reason.
- nubinetwork 2y ago
  It depends on what you're doing I guess... for storage it doesn't make sense, but for pushing a lot of data over a private pipe, why spend the resources adding a cipher?
- jayd16 2y ago
  You'd have to compress every single message separately and then encrypt them. That's still a far cry from being able to compress across every message.
- lxgr 2y ago
  That doesn't allow you to deduplicate across users, though – which of course is the entire point, or the network would be able to see who's forwarding which documents.
dontlaugh 2y ago
I assume some sort of multicast.

jeroenhd 2y ago

It's the evolution of SMS/MMS; development started 18 years ago, in 2007. The modern spec is based on that with a whole bunch of additional revisions for things like video calling and transferring money. It was designed long before major messenger apps had e2ee in the first place. Had it been designed with the security practices at the time, the protocol would've been ossified to the point of being practically insecure by today's standards. In a sense, the fact nobody cared about it until the spec was old enough to drive is actually good for users. The GSMA which designs RCS also serves the needs of government agencies that are tracking (international) criminals, so I bet there must have been some pretty strong opposition against E2EE in the official spec. Frankly, I'm surprised they're even putting it in the spec.

izacus 2y ago

Encryption and privacy isn't an issue for carriers, which were part of the standard body and operate SMS protocol even in 2025. You assume everyone has the same goals in mind :)

lxgr 2y ago

Phone calls aren't encrypted either, if you think about it [1]. There's a large expectation of the telecommunications industry to be able to perform legal interception, and providing end-to-end encryption out of the box might be seen as a direct violation of that requirement. [1] Except, somewhat incongruently, between Google Fi subscribers on some Android phones: https://support.google.com/fi/answer/11295314?hl=en https://support.google.com/fi/answer/11295314?hl=en – no idea how that came to be and how it even works! I suspect it just upgrades to a FaceTime-like VoIP call.