emdee/tox_profile
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update 'MultiDevice Announcements POC'

emdee 2022-10-07 22:06:20 +02:00
parent 1a2b5f8755
commit 22b10c617d
1 changed files with 31 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
MultiDevice-Announcements-POC.md

@ -23,18 +23,14 @@ So we could get the whole network switched over to accomodating PersonaIDs with
## MultiDevice Announcements Push
So if we modify the library and clients as described in MultiDeviceAnnouncementsPOC
how do we keep it up to date when a friend changes his devices.
how do we keep it up to date when a friend changes his devices?
If we know the PersonaID, how is the library code table of PersonaID to ToxPk mapping updated. We want this to be mainly automatic without bothering the user.
We would need to modify the profile code to save a copy if the mapping table,
so that when we start up a client, the mapping table is filled with last good values from the profile. This might not be saved in a profile - this table spans multiple profiles - one per device.
so that when we start up a client, the mapping table is filled with last good values from the pPersona storage - not saved in a profile - as this table spans multiple profiles.
Lets say we have a friend, and we know his ToxPk. We initially derive his PersonaID by setting it to the friend's public key. We want to watch the DHT announcements for a blob of information that will update our PersonaID mapping to his active ToxID.
Or we could have a automatically created NGC group which includes all of my Friends automatically, that has a steady stream of this update information: the contents of the blob are sent to the group along with a NaCl signature of the contents. The public signing key could be put into the status message field of each user, and if each user put the same signature public key as the status message on each of his devices, then that signature pk can become the PersonaID. The mapping table can be automatically scanned and any entries for which the PersonaID == ToxPk could be automatically updated to use the signing key as the PersonaId. The NGC group does not need to be shown to the user by clients, but the client would parse the stream, and parse the entries, verify the signature based on the signing Pk found in the friend's status message, and the client and library update the PersonaID table.
The clients lets a user push a blob whenever he wants - like when he changes devices. You could push a blob, or have a message containing the blob information pushed to the group of friends.
Lets say we have a friend, and we know his ToxPk. We initially derive his PersonaID by setting it to the friend's public key. We want to watch the DHT announcements , or changes in his status message for a blob of information that will update our PersonaID mapping to his active ToxID.
Some clients may let the user decide whether of not to accept a blob update when it arrives.
@ -44,38 +40,53 @@ So what is the blob of information that is pushed by DHT annoucements, or in the
It has these characteristics:
1) It has 2 things - a name and a payload.
1) It has 3 things - a name and a payload, and a NaCl signature.
2) It is small - 1K to 4K in size.
3) The name is related to, and derivable from, the PersonaID - say the name is the PersonaID for now.
3) As we will need a NaCl signing keypair in order to sign out payload, the name, (PersonaID) can be the public key of the keypair - 32 bytes or 64 hex chars.
4) It it pushed regularly so people can get the PersonaID relatively soon - say hourly for now. Any longer means a person who has not connected to that friend before has to wait longer if they only have a PersonaID. This is also true if we push the blob info to a friend NGC group as the messages are not buffered if offline.
5) It might be encrypted so that the contents can not be seen in transit.
6) It must be signed so that it can be verified to be from the PersonaID.
6) It must be signed so that it can be verified to be from the PersonaID, so we will assume every person generates a NaCl signing keypair and uses the same keypair for all of his devices.
Pushing the blob through DHT announcements would mean that the PersonaID to ToxPk mapping could be accessed even by people who were not yet your Friends - helping discovery. This may not be a good idea, depending on if it's encrypted.
So here is a best guess of how the encryption works. I'm not a crypto guy, so please take it with a grain of salt and help with suggestions.
The easier thing to do is to compress and base64 encode the blob, sign it and attach the signature in hex, and keep it under 1007 chars. Then it can be set as your status message on all of your devices. The status message is visible to all of your friends so they all have a copy of the latest blob all of the time.
The blob is intended to be the mapping to an active ToxPk, and could be a mapping to a set of ToxIDs, the set of that Personas devices, with one marked active. This set of ToxPks could be keys that open the encrypted blob. Anyone who already has a ToIPk of the Persona could open the blob to get the update. So this encryption is different from most Tox encryption in that multiple keys can open it.
The blob is intended to be the mapping to an active ToxPk, and could be a mapping to a set of ToxIDs, the set of that Personas devices, with one marked active. This set of ToxPks could be keys that open the encrypted blob. Anyone who already has a ToIPk of the Persona could open the blob to get the update. So this encryption is different from most Tox encryption in that multiple keys can open it - like a multi-key Vera/True/dmwrapper container.
Or it might be enough for the blob to be signed. If the blob had at attached
But it might be enough for the blob to be signed, and that would be a good starting point - add encryption later if needed. If the blob had at attached
signature generated by the NaCl signing functions. This would mean that the owner
of the Persona would generate a NaCl signing keypair to sign the blob. Then the question is how to push th3 public NaCl signing key. Would this work:
1) Set your status message to be the signing public key
2) Do the same with the same key on each of your devices.
of the Persona would generate a NaCl signing keypair to sign the blob. Then either:
1. Set your status message to be the signing public key and push the blob by some means - DHT announcement, universal NGC chat group, some sendfile magic...
2. compress and base64 encode the blob and append it to the public signing key and
put that in the status message if less than 1007 bytes.
You would do the same with the same key on each of your devices.
The blob itself could be as simple as a json or yaml ordered dictionary with the keys being the nickname associate with the PK, and the values the PK or the device.
With the signature and the public key, this should leave room for about 10 devices
in less than 1007 bytes, compressed and base64 encoded.
One problem with this is that only your Friends could verify the blob, which means
users you have never invited will not be able to verify. But perhaps that's good?
users you have never invited will not be able to verify. But perhaps that's good.
Unknown for now is does the client have to send an add request to the new ToxID to make it active if they have never seen it before? I assume yes.
Either way the clients would manage this seemlessly to aggregate the two ToxPks together under one Persona that is shown to the user. The library does most of this by accepting the update from the blob to update the table pointing from PersonaID to the new ToxPk.
The clients would manage this seemlessly to aggregate the ToxPks together under one Persona that is shown to the user. The library does most of this by accepting the update from the blob to update the table pointing from PersonaID to the new list of ToxPks (devices) with the first one being the active one.
Or we could have the DHT announcements have a steady stream of this update information: the contents of the blob are sent along with a NaCl signature of the contents. The public signing key could be put into the status message field of each user, and if each user put the same signature public key as the status message on each of his devices, then that signature pk can become the PersonaID. The mapping table can be automatically scanned and any entries for which the PersonaID == ToxPk could be automatically updated to use the signing key as the PersonaId. Each client would watch the stream for blobs named the PersonaID that they are interested in, which they know from the public signing key being in the status message of the firends.
The clients lets a user push a blob whenever he wants - like when he changes devices. You could push a blob, or have a message containing the blob information pushed to the universal group, or simply put the signing key and a a blob.gz.base64 in the status message.
## MultiDevice Profiles
In order for MultiDevice to work, we need to bootstrap a new devices from an
@ -87,6 +98,8 @@ you cannot have 2 profiles with the same keys online at the same time. We could
The profile rekey utility could also do other things at the same time, like empty the TCP_RELAYS section of the profile if desired. See <https://git.plastiras.org/emdee/tox_profile>
The table of Persona to list-of-PKs would *not* be saved in the profile, as it refers to multiple ToxPKs, and should be easily managed by a keymanager. It's just a json dictionary for each Persona, plus a signing key and a signature. Clients could deal with this easily using the status_message callback.
## MultiDevice Groups
Previously, we described how we simply copy a profile to a new devices and change the public/private keys as a starting point.
@ -113,4 +126,3 @@ These are not simply the keypair of the Persona that is the new profile - how ar
There is Pythonscript to parse profiles that could be modified to rekey them at:
https://git.plastiras.org/emdee/tox_profile