[X3D-Ecosystem] Security for multiparty encryption.

[John Carlson]

At a minimum, the TLS equivalent for UDP, DTLS, should be used to secure
OSC over a WAN, unless other protections, like VPN or security at the
network level (IP) are used.

But security for multicasting (think secure metaverse) is not done like
client/server.  Ultimately, we need get away from centralized governance
for the sake of democracy.

Here’s a strawman security model for multiparty encryption that could be
reviewed.

Copyright 2024 John Carlson

Multi-party encryption
---------------------
Basic ideas:


A sender/client has a server's public key and 5 packets of information:

1. Encrypt recipients' routing information with servers' public keys.
2. Encrypt bulk keys or symmetric keys with recipients' public keys.
3. Encrypt message with bulk or symmetric keys from previous packet.

4. Optionally encrypt packet 1 with sender's private key. (Exercise left to
reader which keys to apply first.)
5. Optionally encrypt packet 2 with sender's private key. (Exercise left to
reader.)

4 and 5 are required for non-repudiation or proving who sent the message.

A sender prepares a message including recipients' routing information,
dependent on which communication network you are on. This may mean IPv4,
IPv6, TCP or UDP port, hostname, message storage agent (MSA--possibly
SMTP/IMAP), message user name, and chat network handle.

The message user agent (MUA) retrieve's the server's current public key,
possibly using a web browser, or web client.

The routing information is encrypted with the server's public key, or a
client/server bulk key previously negotiated between client and server.

Bulk or symmetric keys for the message are encrypted with each recipients'
public key. Either together, or individually.

The message is encrypted with the bulks key(s) for each user or a single
bulk key is use for all recipients.

The sender connects to message transfer agent (MTA), and sends encrypted
routing information, encrypted recipients' bulk keys, and the encrypted
message.

The MTA unpacks the routing information using it's private key, determines
what MTAs or MSAs need to be contacted. It has the MTAs or MSAs private
keys, and rewraps the routing information using the private keys of the
other servers. Not all routing need be included, just that necessary for
each MTA or MSA to transmit the message to the desired recipients.

The package that contains the bulk keys for the message is untouched, as
well as the encrypted message is untouched by the servers.

The new routing information is passed to other servers along with the other
packets.

The recipients do not see the routing information, unless it is
incorporated by the sender. The sender may provide a public key for
verification that they sent the message. The sender's public key might wrap
the bulk or symmetric key in packet (2) above for extra security.

The recipients pick up the message in their message inbox, decrypt the bulk
key using their private keys, and decrypt the message using the bulk key.

John

On Wed, Nov 19, 2025 at 4:06 PM Bergstrom, Aaron <aaron.bergstrom at und.edu>
wrote:

> John,
>
>
>
> Walker, our lab game programmer, did his senior CS capstone on the topic
> of doing mocap with a web cam, and he’s now employed by us full-time.
>
>
>
> I’ve asked him to get the Native Dancer UGE demo app updated to use the
> Movin device as the apps game controller.
>
>
>
> While he’s doing that, I will have him look into the device’s
> implementation of OSC.
>
>
>
> In recent Discord posts, the company announced that different skeleton
> formats could be added to the device OSC support through their Movin Studio
> software.
>
>
>
> Aaron
>
>
>
> *From:* John Carlson <yottzumm at gmail.com>
> *Sent:* Wednesday, November 19, 2025 4:00 PM
> *To:* Bergstrom, Aaron <aaron.bergstrom at und.edu>
> *Cc:* X3D Ecosystem public discussion <x3d-ecosystem at web3d.org>; Don
> Brutzman <don.brutzman at gmail.com>
> *Subject:* Re: [X3D-Ecosystem] OSC mocap support in X3D Browsers
>
>
>
> I think the issue will be your device’s implementation of OSC. Without
> that, I don’t think we’ll get anywhere.   It be good to know what software
> your device is compatible with.
>
>
>
> John
>
>
>
> On Wed, Nov 19, 2025 at 3:42 PM Bergstrom, Aaron <aaron.bergstrom at und.edu>
> wrote:
>
> John,
>
>
>
> I appreciate your enthusiasm, but I don’t think we are ready to move
> forward on a project at this time.
>
>
>
> While someone hasn’t implemented OSC yet, it’s good to know that it’s
> possible once our lab is ready to move forward. That might be a while yet
> though.
>
>
>
> Aaron
>
>
>
> *From:* John Carlson <yottzumm at gmail.com>
> *Sent:* Wednesday, November 19, 2025 3:35 PM
> *To:* X3D Ecosystem public discussion <x3d-ecosystem at web3d.org>; Don
> Brutzman <don.brutzman at gmail.com>
> *Cc:* Bergstrom, Aaron <aaron.bergstrom at und.edu>
> *Subject:* Re: [X3D-Ecosystem] OSC mocap support in X3D Browsers
>
>
>
> Read references here:
>
> https://en.wikipedia.org/wiki/Open_Sound_Control
>
>
>
> Not really a standard!
>
>
>
> Perhaps we should wait for a mocap standard?
>
>
>
> John
>
>
>
> On Wed, Nov 19, 2025 at 1:03 PM Bergstrom, Aaron via X3D-Ecosystem <
> x3d-ecosystem at web3d.org> wrote:
>
> Do any of the X3D Browsers support the OSC mocap protocol, or is anyone
> working on a project that is using both X3D and OSC?
>
>
>
> I just purchased a Movin Tracin device for the DREAM Lab, and as of v2 of
> Movin Studio, it now supports OSC applications.
>
> https://www.movin3d.com/tracin
>
>
>
> I would just like to see if I could get it working with one of the X3D
> Browsers.
>
>
>
> Aaron
>
> --
> X3D-Ecosystem mailing list
> X3D-Ecosystem at web3d.org
> http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20251119/a85f7bbd/attachment-0001.html>