Still waiting on a non-Google implementation of this so-called standard.
Apple will soon support encrypted RCS messaging with Android users
21–30 of 270 posts
Re: Apple will soon support encrypted RCS messaging with Android users
#22Any news on if/when one will be able to send RCS from a program or device outside the monolith?
Re: Apple will soon support encrypted RCS messaging with Android users
#23Any news on if/when one will be able to send RCS from a program or device outside the monolith?
Never. It is just a fancy MMS in new disguise. Carriers / patent holders will hold to it forever while praising it as the new best thing.
Re: Apple will soon support encrypted RCS messaging with Android users
#24Why 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.
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.
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.
Re: Apple will soon support encrypted RCS messaging with Android users
#25So essentially, it's not really an Apple thing, it's more that the universal RCS profile just didn't have encryption, and Google RCS was a non-standard extension that nobody else was allowed to use. The real news is the update to GSMA RCS, because without that, none of this matters. What I'm missing in the article is who's going to own the keys and why this is probably going to default to the telcos as if it's MMS. A…
I understand your point that the "news" part is that RCS standard now includes E2EE, rather than about Apple's support for said standard.
But I don't think it's fair to suggest or imply that this development is unrelated to Apple either.
RCS has been a thing for nearly a decade, and Google's RCS backend has been doing non-standard E2EE for half that time.
Within 8 months of Apple publicly announcing they would adopt RCS and work with GSMA to support standardised E2EE, there is suddenly a standard for it...
Re: Apple will soon support encrypted RCS messaging with Android users
#26So essentially, it's not really an Apple thing, it's more that the universal RCS profile just didn't have encryption, and Google RCS was a non-standard extension that nobody else was allowed to use. The real news is the update to GSMA RCS, because without that, none of this matters. What I'm missing in the article is who's going to own the keys and why this is probably going to default to the telcos as if it's MMS. A…
Is there anything that shows "no one was allowed to use it" or was it that it wasn't an accepted standard?
Look at Google’s documentation: they explicitly state that only their Messages app is allowed to talk to their key exchange server. The entire marketing campaign they ran about RCS was predicated on nobody reading their docs or noticing all of the Android developers begging for permission to use RCS for years.
https://www.gstatic.com/messages/papers/messages_e2ee.pdf
> E2EE is implemented in the Messages client, so both clients in a conversation must use Messages, otherwise the conversation becomes unencrypted RCS. In rare situations where the conversation starts as E2EE, then one of the clients migrates to a different RCS client or an older Messages client that does not support E2EE, Messages might be unable to detect the change immediately. If the Messages user sends a new message, it’s still E2EE, however the recipient client may render the encrypted base64 payload directly as message content.
Re: Apple will soon support encrypted RCS messaging with Android users
#27Why 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.
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.
I assume some sort of multicast.
Re: Apple will soon support encrypted RCS messaging with Android users
#28Earlier quoted context omitted.
Is there anything that shows "no one was allowed to use it" or was it that it wasn't an accepted standard?
Yes, Google only made it available for Google Messages. They don't have an SDK or API you can use to make your own clients or servers. Google also didn't put it up for standards with the GSMA or any other standards body, at least not publicly. There are no records of it. There are some older submissions here you can probably find using one of the HN search sites about this, but IIRC those didn't really have any inter…
The destruction of third party apps has been totally wild.
I'm very curious how long this OS-coupled status quo is going to go on for.
Re: Apple will soon support encrypted RCS messaging with Android users
#29Earlier quoted context omitted.
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.
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.
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?
Re: Apple will soon support encrypted RCS messaging with Android users
#30So essentially, it's not really an Apple thing, it's more that the universal RCS profile just didn't have encryption, and Google RCS was a non-standard extension that nobody else was allowed to use. The real news is the update to GSMA RCS, because without that, none of this matters. What I'm missing in the article is who's going to own the keys and why this is probably going to default to the telcos as if it's MMS. A…
The encryption is based on MLS: https://www.rfc-editor.org/rfc/rfc9420.html
I don't think Google wanted to gatekeep their E2EE implementation. They have some generic documentation about how it works: https://www.gstatic.com/messages/papers/messages_e2ee.pdf
The thing about RCS is that no messengers seem to care at all about implementing RCS themselves. Part of that is probably because depending on the carrier, RCS may require access to certain SIM card information, which only pre-installed apps can do, and part of it is that many developers are waiting for Google to add RCS to the same API that SMS/MMS already exposes because they don't want to implement RCS themselves.
Realistically, the target demographic for their documentation is 1) Apple (who they'd happily supply with details to get rid of the green bubble problem) and maybe 2) government officials looking into antitrust concerns. In theory someone working for LineageOS can implement an RCS client, though, but for those developers I don't think reverse engineering the remaining unknowns about the protocol (mostly "what server" and "what message contents") aren't that difficult.
I'm not cryptographer, but I haven't heard any major issues from actual cryptographers about MLS. It's encryption principles seem to be similar to those of Signal. Google is actually already using MLS in their proprietary E2EE implementation.
Ideally, MLS would be combined with MIMI so that messaging apps become interoperable, but that's probably a pipe dream.