Suggestion: Generating Asymmetric Encryption for Messaging: Groups and DM


#1

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.

Premise:

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.

Details

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.

  1. 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:
  2. 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.
  3. Send request to local domain (A) with to Forward to Domain B
  4. Domain A looks up if it can connect to Domain B. If it can, then
  5. Domain A sends message to Domain B
  6. Domain B delivers message only to User Y as they are logged in
  7. 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
  8. 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.
  9. 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

  1. Online Users A, B, C, D belong to a group, they are located in Domains X, Y, Z.
  2. User A sends a message to group
  3. Retrieve public key of group
  4. Encrypted message M using group public key

Then for each user B, C, D

  1. Look up user public key and location
  2. Enclose Encrypted Message M to Message O with Message type. for User
  3. Encrypt Message O and App sends to Current Domain
  4. Current Domain checks message destination, if remote then sends to remote domain
  5. If the Same, then doesnt do anything with it, as it has already been received.
  6. 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.

Requirements

  • 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.

Benefits:

  • 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.

Disadvantages

  • 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.

#2

I would add also:
Eventually, from the user directory page, a “Contact” button to request a key sharing.


#3

I think it’s acceptable.

I experienced text communication with a more delay than that. And it was not really an issue.


#4

I few notes on this…

  • Generating public/private keypairs is an expensive operation, so it shouldn’t be done as part of the protocol, just offline. Encrypting with a private key is somewhat expensive.

  • HiFi already has a public/private keypair used for the wallet/blockchain.

  • I’m not a huge fan of building new crypto protocols. It’s too easy to make mistakes, to leak information, etc. I’d recommend looking hard (really hard) for existing encrypted protocols for message passing. Minimally, have crypto protocol experts take a hard look at the design and source code.

  • I like p2p…no messages at all passing through a domain server, just directly from client to client. Using domain servers to set up the connection may be okay, but I’m still not a huge fan. Too easy to domain servers to nab messages/interfere with communication.

  • I’d love to minimally see some way for those not currently logged in to a domain to chat p2p. Perhaps even using existing chat clients (XMPP, etc.)

  • The blockchain may have interesting implications with respect to identity storage, public key access, etc. allowing some stuff to be done in a distributed manner without worrying about domains.


#5

Generating public/private keypairs is an expensive operation, so it shouldn’t be done as part of the protocol,

The idea was to have all of this done on the client and use existing methods, like rsa to generate the pairs. You wouldn’t generate per each message or session, but by each identity.

the messaging system between domains could be used for other things as well. With or without encrypted message. You simple have a payload thats sent to another domain.

Others can roll what ever on top.

Encrypting with a private key is somewhat expensive

You mean public key, since assymetrical use public private pairs instead of a shared secret. Regardless yeah sorta, which is what I addressed in the downsides

HiFi already has a public/private keypair used for the wallet/blockchain.

While would be great I would suggest having a separate keypair for comms, as entering passwords multiple times is a UX pain. Could be apart of the same chain or a second pair connected to wallet.

I’m not a huge fan of building new crypto protocols. It’s too easy to make mistakes

I wasn’t saying rolling our own cryptographic methods…
Instead we use existing ones or we could go big standard and could be jwt nested jwe ES384 as a baseline, where jwt is used as identity confirmation and jwe to encrypt it. Which still would meet my above discussion.

I like p2p…no messages at all passing through a domain server, just directly from client to client. Using domain servers to set up the connection may be okay, but I’m still not a huge fan. Too easy to domain servers to nab messages/interfere with communication.

Which is why

A. Messages should be encrypted, preventing the message from being read by individuals without the secret if running a modded receiving domain

B. I suggest the shared secret to hash sign messages with. That way while you could technically send a fake message pretending to be someone, the receiving client app can ignore it and future requests.

C. Domain sends message directly to receiving client.

This way you use mostly existing systems

Simplified:
A: Generate a keypair in client like the wallet, but for comms, and allow script API to use these (send public key and use private key to decrypt something)
B: Allow Domains to Message Each other
C. Allow targeted messaging from domains to connected agent instead of just broadcast

For groups however would need something that would be with the groups instead, and since groups is a high fidelity Inc generated thing they’d be controlling from their end.

I mean anyone could do a XMPP implementation or other right now, however what is aimed here is something that’s by default in the client.


#6

Protocols (not crypto) are very prone to issues/misimplementation/design flaws as well, and the mechanism for encrypting (using known crypto), passing messages, etc. is a secure protocol.

As far as XMPP, I do think it’s completely feasible for someone to add the backend code to deal with XMPP to the interface, allowing integration with the people app/chat apps. One library that could be added is libjingle, which is google’s implementation of XMPP + ICE/STUN/etc. for direct p2p messaging. I believe steam uses that library for their messaging, so supporting that would allow messaging with steam users, for example.


#7

Oh, I should add…as an example of a protocol issue…

Routing traffic through a domain (instead of p2p) allows the domain owner to see who is talking to who, which is leaked information.


#8

Is there anyway a need for a “domain public chat”?
When you are in presence of people, the convention is already to use voice.
(and a mix of text and voice in a conversation is really a pain)
If you are distant, then using text chat for “user to user” or “user to group” make sense.

I think too that it should not be supported by the domain server.


#9

The thing is, that is an agreed consensus with many new users coming in. Regulars are very used to voice chat because that is the primary communication method. However, there are times when voice chat isn’t’ ideal or that some people just don’t want to use it.

An issue with P2P is that it isn’t always available as an option. One big part of that is again a concern with trust on a server (domain), since the connection points HAVE to be announced somehow. Not to mention, the whole point is to have an in-house solution, not an external. If you want an external solution… then use the external solution.

One idea I had was a domain trust system, where some users, when forming their connections, can agree to certain domains as being trustworthy. By doing this, messages can just be relayed from there, treating it as though it were an inbox of sorts. Of course, this boils down to if the users CAN trust a domain, but that’s just my 5 cents on the matter. Part of all this talk is also a bit why the wallet system is as it is, so a solution found here can hopefully also be applied for the wallet system, allowing anonymous wallet accounts again.


#10

I think it’s more about using all the same solution, whatever it is.
Embed it in the “hand shaking”, in the “People” app, in the “User Directory”… Should work.
Then there is the problem to get authenticated in this “whatever it is” solution, this is precisely why it needs to be “in-house”.


#11

Not domain wide. but local chat that stops at some distance is for sure needed. Voice is not something all people like to use. For myself, it’s nice if you can fall back to text chst because voice fail or you cannot voice at that moment.

So local chat is needed, give it a range of 25 meters and then stop.

Voice only chat is a pain, high fidelity did proof that always. and sansar confirmed it. lucky you did have chat there.


#12

Some features I’d love to see in p2p/group chat…

  • invites, i.e. “Join me in domain xyzzy”
  • The ability to paste url’s in chat, and follow those urls with a click (or VR equivalent)
  • The ability to share images/videos (snapshots)
  • Integration with Steam, Twitch, etc. for users not currently logged in to hifi. (Okay, maybe I’m dreaming. Let me dream.)
  • history (so I can look up URLs someone pasted days ago)

#13

Emotes gifs giphy file sharing mind melds mobile phone intergation
It’s a pointless discussion if it’s not on by default
Philip says no
So why even dream.


#14

Definitely…


#15

Not sure Sansar has confirmed anything.
Go in Vrchat, you have significantly more people there and they are voicing.


#16

Not trying vrchat anymore. tried it 2 times. and it created 2x problems. Mabye uf the add option that blocks steamVR from running hidden in the background…

Yes, people use text chat in sansar. i also did need ti use it because some problems with voice.

Besides, not want to use voice always. Text is so much more relaxed. Most people i know would anyway aim for text chat.

@judas, mabye time that someone change mind and turn chst on by default. You not make a platform bug if you only aim for small VR market.

For a new 3D platform that need to get 3D internet. it’s just a terrible idea to have chat not default implemented. And try to force users to voice only and let’s make it complex to use chat fir new users. (first need to know there’s app. then you need to find and install it)

Feels a bit like people buy a pc and the need to install windows from cd before you can use it.


#17

Even if they greenlight it , they will just build it without any thought to the design or functionality
like they did with the inworld build tools re design
and how do we all love those :stuck_out_tongue:

NEVER LET CODERS HANDLE DESIGN ther choices are based about what they can do rather than what we need

For example who pictured vr as using stupid wandy controllers
I want gloves I want hands. Not this idiotic lets move things with chopsticks solution