You aren’t sending iMessages. You’re sending text messages, and vice versa. Old school SMS and MMS (from the days of the first cameraphones…the standard hasn’t changed much since then) are the best common language between your phones.
Google/Android support RCS, the open modern protocol to replace SMS/MMS, and Apple is being sluggish to implement. Apple also supports iMessage, the default enhanced language to replace SMS/MMS, but that’s a closed protocol, and as such only supports Apple.
Sent from wefwef for iOS, but I’d still say Apple are the assholes here. The only reason I even have a damn iPhone is because most of the people I exchange pictures/videos with, and the people they exchange pictures and video with, happen to use iPhones. So there’s no incentive for all of them to switch to a third-party platform for just me.
One of the problems with rcs is that some features like encryption are handled by the rcs provider, and if you’re not using googles rcs server you don’t get it.
Citation needed. I don’t know enough about the protocol, but it would be foolish for Google to hold the keys, when PKI is literally sitting right there and is a perfect solution for end to end encryption since, ya know, that’s why it was invented.
And reading a little bit about RCS, it seems like that’s what they are doing, since Google doesn’t hold the keys. It’s more likely they are a key management server, which publishes the public keys of all users.
And that’s fine. Public keys need to be available, that’s how it works. Each key is generated as part of a pair, a private side and a public side.
Here’s how it works:
User 1 generates a key pair. The pair contains a private side and a public side.
The private side is retained by User 1. The public side is published in KMS.
User 2, repeat.
User 2 wants to contact User 1 and locates them in the KMS (from their experience, this is “enter users phone number”)
User 2 composed a message. To them, it just has a destination and a body. But behind the scenes, it looks more like this pseudocode.
message = {
“destination”: “user1@ gmail.com”,
“message”: “User1, there are hot single milfs in your area\nRespond with your credit card number for more info.\nTo stop, reply with your social security number. “}
my_public_key = “blahblahblah”
message[“body”] += f”\n{my_public_key}”
result = sendmessage(
destination=message[“destination”],
contents=encrypt(
key=findpubkey(
query=message[“destination”]),
contents=message[“body”]))
User 1 receives the message. Since he holds the public key, only he can decrypt it. He now has the public key since user2 so helpfully attached it to their body…though now that I think about, that shouldn’t be necessary as long both users are registered in a KMS and both users know (and trust!) the KMS where the other user is registered.
Note the bit about trusting the KMS. It’s mostly about trusting them to say “this person definitely gave me this public key and told me it’s them, so they must have the private key”. There are obvious inherent risks here. The most obvious drawback and weakness of the KMS system is really in protecting the key, and since that task is delegated to the users, it needs to be pretty foolproof that it works and they can’t accidentally export it. Exporting the key would mean that the user could be spoofed until they deregister the corresponding compromised public key(s) in KMS.
However, that drawback beats the drawback of the other major usage of PKI, at least in this particular instance, and thats CAs. If a central CA were to be used, and were talking about a very small number of application publishers, then messages could easily be intercepted by the CA or anyone with access to their keys. That works better in much larger systems, where there’s competition for CAs and trust lists are distributed out-of-band (by Microsoft/Apple/Mozilla/etc), or entirely closed systems where “identity” is the chief concern over “privacy” (like internally within the walled garden of PlayStation Network). It could be adapted in that way. Old fashioned secure email works that way. But it would require users getting their own certificates from public CAs and even with current automations, it’s still an expensive and technical process not really fitting for mass-market instant messaging (but great for a security-conscious crowd).
The public side can be distributed freely and the private side gets retained by the holder. It can be backed up by Google, and associated with the account, but it’d be a major security oversight that literally any security professional would ragequit over if the KMS had any sort of access to that.
I suspect Apple will also run their own directory/kms, or there’s a means to search users across multiple directories/reams built into the protocol.
It’s okay to be suspicious, especially of Google. And PKI is really confusing concept (that ultimately just boils down to “trust me bro”). But from my perspective it seems like you are fundamentally misunderstanding the technology, based on what I could find in literally 15 seconds of a web query.
There’s no rcs encryption standard. Google messages does it the same way as signal (pki, like you described), but you’re either remotely accessing googles server by signing in on the web or downloading their google messages application from the play store, their server.
E: I should have used more clear and precise technical language in my previous post.
Are you saying Google “holds the keys [to the castle]”, as in you have to go through them to access the app? Or because they are the only ones supporting end-to-end encryption between their users?
The former should be able to be fixed with external app stores. The latter is a bit more difficult and would probably require changing the standard since, you’re right, E2EE is a Google Messages feature, not an RCS feature.
If I were working on the standard, I’d probably add support for KMS/Relay servers on specified SRV records for a domain. KMS could even be optional with TXT records for an individual users public key. Then just layer on GnuPG or something similar. This would also make it easier for vanity/personal domains for RCS addresses.
honestly im saying both. google has the only e2ee rcs implementation and they require you use their software and afaik haven’t opened up that part and have no plans to.
becoming corporate citizens is the solution presented to common carrier surveillance and its a bummer.
relying on dns opens the end user up to cert attacks and everyone already just clicks through whatever cert acceptance popup their provider throws out so the eu almost doesn’t need to mandate everyone accept nation certs.
I have Andriod and my wife’s got iPhone. IMessages don’t deliver… or deliver hours later. Images don’t make it… or make it xna they are potato.
You aren’t sending iMessages. You’re sending text messages, and vice versa. Old school SMS and MMS (from the days of the first cameraphones…the standard hasn’t changed much since then) are the best common language between your phones.
Google/Android support RCS, the open modern protocol to replace SMS/MMS, and Apple is being sluggish to implement. Apple also supports iMessage, the default enhanced language to replace SMS/MMS, but that’s a closed protocol, and as such only supports Apple.
Sent from wefwef for iOS, but I’d still say Apple are the assholes here. The only reason I even have a damn iPhone is because most of the people I exchange pictures/videos with, and the people they exchange pictures and video with, happen to use iPhones. So there’s no incentive for all of them to switch to a third-party platform for just me.
One of the problems with rcs is that some features like encryption are handled by the rcs provider, and if you’re not using googles rcs server you don’t get it.
Citation needed. I don’t know enough about the protocol, but it would be foolish for Google to hold the keys, when PKI is literally sitting right there and is a perfect solution for end to end encryption since, ya know, that’s why it was invented.
And reading a little bit about RCS, it seems like that’s what they are doing, since Google doesn’t hold the keys. It’s more likely they are a key management server, which publishes the public keys of all users.
And that’s fine. Public keys need to be available, that’s how it works. Each key is generated as part of a pair, a private side and a public side.
Here’s how it works:
User 1 generates a key pair. The pair contains a private side and a public side.
The private side is retained by User 1. The public side is published in KMS.
User 2, repeat.
User 2 wants to contact User 1 and locates them in the KMS (from their experience, this is “enter users phone number”)
User 2 composed a message. To them, it just has a destination and a body. But behind the scenes, it looks more like this pseudocode.
message = { “destination”: “user1@ gmail.com”, “message”: “User1, there are hot single milfs in your area\nRespond with your credit card number for more info.\nTo stop, reply with your social security number. “} my_public_key = “blahblahblah” message[“body”] += f”\n{my_public_key}”
result = sendmessage( destination=message[“destination”], contents=encrypt( key=findpubkey( query=message[“destination”]), contents=message[“body”]))
User 1 receives the message. Since he holds the public key, only he can decrypt it. He now has the public key since user2 so helpfully attached it to their body…though now that I think about, that shouldn’t be necessary as long both users are registered in a KMS and both users know (and trust!) the KMS where the other user is registered.
Note the bit about trusting the KMS. It’s mostly about trusting them to say “this person definitely gave me this public key and told me it’s them, so they must have the private key”. There are obvious inherent risks here. The most obvious drawback and weakness of the KMS system is really in protecting the key, and since that task is delegated to the users, it needs to be pretty foolproof that it works and they can’t accidentally export it. Exporting the key would mean that the user could be spoofed until they deregister the corresponding compromised public key(s) in KMS.
However, that drawback beats the drawback of the other major usage of PKI, at least in this particular instance, and thats CAs. If a central CA were to be used, and were talking about a very small number of application publishers, then messages could easily be intercepted by the CA or anyone with access to their keys. That works better in much larger systems, where there’s competition for CAs and trust lists are distributed out-of-band (by Microsoft/Apple/Mozilla/etc), or entirely closed systems where “identity” is the chief concern over “privacy” (like internally within the walled garden of PlayStation Network). It could be adapted in that way. Old fashioned secure email works that way. But it would require users getting their own certificates from public CAs and even with current automations, it’s still an expensive and technical process not really fitting for mass-market instant messaging (but great for a security-conscious crowd).
The public side can be distributed freely and the private side gets retained by the holder. It can be backed up by Google, and associated with the account, but it’d be a major security oversight that literally any security professional would ragequit over if the KMS had any sort of access to that.
I suspect Apple will also run their own directory/kms, or there’s a means to search users across multiple directories/reams built into the protocol.
It’s okay to be suspicious, especially of Google. And PKI is really confusing concept (that ultimately just boils down to “trust me bro”). But from my perspective it seems like you are fundamentally misunderstanding the technology, based on what I could find in literally 15 seconds of a web query.
There’s no rcs encryption standard. Google messages does it the same way as signal (pki, like you described), but you’re either remotely accessing googles server by signing in on the web or downloading their google messages application from the play store, their server.
E: I should have used more clear and precise technical language in my previous post.
Are you saying Google “holds the keys [to the castle]”, as in you have to go through them to access the app? Or because they are the only ones supporting end-to-end encryption between their users?
The former should be able to be fixed with external app stores. The latter is a bit more difficult and would probably require changing the standard since, you’re right, E2EE is a Google Messages feature, not an RCS feature.
If I were working on the standard, I’d probably add support for KMS/Relay servers on specified SRV records for a domain. KMS could even be optional with TXT records for an individual users public key. Then just layer on GnuPG or something similar. This would also make it easier for vanity/personal domains for RCS addresses.
honestly im saying both. google has the only e2ee rcs implementation and they require you use their software and afaik haven’t opened up that part and have no plans to.
becoming corporate citizens is the solution presented to common carrier surveillance and its a bummer.
relying on dns opens the end user up to cert attacks and everyone already just clicks through whatever cert acceptance popup their provider throws out so the eu almost doesn’t need to mandate everyone accept nation certs.
My mom had the same problem. She has a 6 year old iPhone and sometimes my messages are delivered days after I send them. Happened a lot last year…