One of the things that I have been thinking about recently is returning back to the communication methods we currently have and the ever requested feature of text chat,
Specifically Direct Messaging and Group Messaging:
This is a tech post and technology specific discussion post. So beware normies:
Also as a preface, I have no detailed experience with cryptography, so all of this is based on my own theories and concepts.
Currently the thing that is stopping us from having this sort of feature by default is that anything sent over the messaging system would still be susceptible to interception on the domain level and anyone with a bit of scripting knowledge will be able to effortlessly read whats going on.
So how about using Asymmetric Cryptography for this, and then using the distributed nature to the advantage?
Allow Clients to generate public private key pairs on request, and allow the public key to be shared when making a contact, or to a remote High Fidelity Server.
When you log in, and you connect with a computer and don’t have a pair generated, you generate a asymmetric pair and only send the public key to a High Fidelity server, that would behave as your currently active key. This should be configurable from the client where to send the public key to and you should be able to generate a new key at any time you want.
When you shake hands with a user you share your public keys with each other.
Each user then shares a random secret encrypted with the public key with each other. The clients stores what they shared and what they got with whom.
- User X client app looks up status, public key and location (Domain B) of User Y when opening up messaging window. If on Friends List, Online and in a reachable server, continues:
- User X Use public key of User Y to encrypt message, and adds a signature, which is simply a truncated hash based on the secret + non-encrypted version of the message. The message contains an non-encrypted destination Domain.
- Send request to local domain (A) with to Forward to Domain B
- Domain A looks up if it can connect to Domain B. If it can, then
- Domain A sends message to Domain B
- Domain B delivers message only to User Y as they are logged in
- User Y’s client app receives Message requests, checks if “from” Exists in User Y’s friend list, and if so, uses User Y’s private key to decrypt message
- User Y checks decrypted message with known sent secret with the hash. If this does not succeed, do not show it, and ignore future messages from the fingerprint.
- Repeat with User Y to User X, and so forth
Message would have a public non-encrypted message id, that domain A knows, and to which the receiving client can respond with to the Domain A.
Similarly when a group is created on HiFi’s services, a public key and a private key is generated for that group: Group Members have access to the public keys of all the members, and the public key of the group. This way, harder to forge messages as if they are coming to the group.
Group information, also should have information on locations of all the members, or to keep privacy consistant, messages are sent to hifi.
When a Message is sent to a group, it would behave in the following method
- Online Users A, B, C, D belong to a group, they are located in Domains X, Y, Z.
- User A sends a message to group
- Retrieve public key of group
- Encrypted message M using group public key
Then for each user B, C, D
- Look up user public key and location
- Enclose Encrypted Message M to Message O with Message type. for User
- Encrypt Message O and App sends to Current Domain
- Current Domain checks message destination, if remote then sends to remote domain
- If the Same, then doesnt do anything with it, as it has already been received.
- User receives message, and uses first the private key to decrypt message, where as the type of the message is discovered then: user then uses the group private key to decrypt it for the user chat.
If a user is kicked from the group, a new group pair is generated. And off hand This could also be cycled every few day, after all, as groups are a subscription paid feature.
To stop any Forging of messages, each message should have some sort of user signature, signed by the domains that the message was sent from the domain by the username, still figuring out how that would be doable. Group Messages should have a group signature.
Maybe have a shared secret established as soon as the public ones are signed, that would be used to validate against a hash.
Alternatively, if High fidelity doesn’t want to host a public / private keys on a remote,
only share public keys to who ever you are friends with. Forexample, if you shake someones hands, you could share each other’s public key on the spot to each other.
- A public / private is generated for
- Groups (on hifis end)
- Users (on individual devices)
Both should be genera-table on the fly, or when there is a major change (user logs in from another machine, or when group members get removed) or even renewed by having them expire after a while.
- Users to share public keys on handshake, and create a shared secret on messaging.
- Domains must be able to directly communicate with each other: Domain to domain Messaging.
- Messages between domains must be time stamped
- Domains must be able to disable receiving of remote messages if they are not able to handle to load
- Domains must be able to block users spamming the remote private messages with rapid messages one after another. Group messages must should have their own limit.
- Needs Cryptographic Script Interfaces in the client that can be accessed by the client.
But this can completely by Client App Specific: public keys could be hosted elsewhere than High Fidelity or
Ideally they should be shareable on contact with individuals, and only hosted locally, but this is not doable for groups.
- Somewhat Encrypted Communication: Only the receiver and sendee know what transpired, but individuals may know that something was being messaged.
- Utilizes mostly existing systems, requiring a handful of things.
- Could allow for domain only private channels.
- Allows for Private and Group Messaging.
- Allows Clients to indicate if message is received or not.
- Clients can decide what to do with the received messages
- can be semi distribute if user info could be propegated somehow with permissions
- Can use Keys to communicate from domain to user.
- Encrypted Communication: Alas, security wise you cant really see whats being communicated so you can ban harassers and assholes as a domain admin.
- Slowness: this method requires quite a bit of crunching power on the sending and receiving end compared to others, so sending / receiving messages may take a half a second or more longer + added latency from domain looking up where you are, and then messaging to the other domain.
- potential limit to message size.
- Not Fully decentralised method of communication; but Alternative methods could be found to find the domain names where users are at.
- Changing devices may cause issues when sharing a secret
- If the public key is not on a remote only accessible by friends, and is shared on a domain, the owner of the domain where the secret is shared could technically spoof the secret for both, unless client to client sharing of info could be achieved on the same domain.
- Domains can choose to block DMs in the domain by disabling the feature all together, but this is a double edge sword: can create “Deadzones” where people can work in relative peace,
- DDOSable: You can clog up the messaging thread when sending messages between domains and can be easilly distributed by doing it from multiple domains. But thats why domains should be able to turn the feature off.
- If one needs to renew private keys and is not remotely sending the new public keys to the server, the public keys can be out of date, and cannot be received.