✏️ [ FEAT REQ ] Encrypted text messages with other Quik users

[Dyras]

Is your feature request related to a problem? If so, please describe the problem. There is damn near no security for regular SMS at all. Sure, RCS is slowly coming, but that seems to be Google Messages exclusive + it's not really SMS. You're still using data for it.

Several apps have tried it, but they are either abandoned (Silence, Partisan SMS) or too new to be used in practice (Deku SMS).

Hence I would suggest..

Describe the feature you'd like The ability to encrypt your SMS messages with other Quik users. I think that so far, Silence has done it the best with forward secrecy, etc.

Basically, I want the ability to opt-in to using encryption with other people using Quik, so that the telephone company can't read the contents of your text messages.

Additional context Yes, I know that (insert non-SMS app) is encrypted. On the rare occasion that I send an SMS with a friend, I would still prefer it if that was encrypted rather than unencrypted as is the case with darn near every SMS sent worldwide today.

Additionally, in some cases SMS will be the only way of communicating, for example, if the data network isn't working.

[octoshrimpy]

I once cooked up an idea of using stegcloak and the first couple SMS for a handshake on cryptography, but haven't really tried it before.

[octoshrimpy]

---

main system

first message sent includes secure layer message containing

Alice: "hey I'm on matrix, are you?"

second message sent will not include any more secure layer content, unless user specifies to resend handshake within conversation settings

Alice: (N/A)

upon receiving a secure layer request, the client will prompt the user for handshake

Bob - [ Alice wants to handshake ]

upon handshake request, user may decide one of three things

1. Bob - yes

• prompts end of handshake
• convo will be moved to new protocol

2. Bob - no

• prompts end of handshake
• convo will remain where it is
• both clients will no longer attempt to find secure layer messages

3. Bob - "ghost"

• does not end handshake
• Bob's client pretends it never saw the message and is on a non-moxie client
• Bob's client will no longer attempt to find secure layer messages

Bob - no upon receiving no, client will no longer attempt to find secure layer messages

Bob - "ghost" client will never receive "ghost", as it's never sent

Bob - yes upon receiving handshake "yes", client will prompt user to send own matrix username Alice: "[email protected]"

1. upon receiving hash and username, client can decide whether to finish handshake, or cancel

Bob - [email protected]

Bob - yes

• finalizes handshake
• client sends hash of own username as activityPub message
• client takes received matrix username and inits connection through matrix protocol

Bob - no

• prompts end of handshake
• convo will remain where it is
• both clients will no longer attempt to find secure layer messages

Bob - "ghost"

• Bob's client pretends it never saw the message and is on a non-moxie client
• Bob's client will no longer attempt to find secure layer messages

upon receiving a matrix message, check if incoming username hashes to a received handshake if yes, tie the two together

Alice

---

here's the main idea. it was for shifting over to matrix, but the same idea could be used for instead accepting crypto keys

[Dyras]

I believe in you man. Make us proud!

Say the word and you have a donation every month to motivate you to figure this out.