multidevices support about toxcore

[jackzhp]

for 0x84 message,
to support multidevices, indicator1 ==3,4,5,6 are defined:
encrypted = indicator1(3) + deviceID + pingid32 + nodes + mac16 to indicate not setup
encrypted = indicator1(4) + deviceID + pingid32 + nodes + mac16 to indicate setup
encrypted = indicator1(5) + numberOfDevices1 + deviceID + pkWormHole32 + deviceID + ... + nodes + mac16 to indicate not found
encrypted = indicator1(6) + numberOfDevices1 + deviceID + pkWormHole32 + deviceID + ... + nodes + mac16 to indicate found
when deviceID is null, then 0x84 returns all entries to multidevices of the same real PK.

[GrayHatter]

Ignoring the fact that this would require the same pubkey to exist on multiple, which isn't something toxcore will support.

This is rather hard to parse and understand; so I'm going to close this issue. If you'd like to continue the discussion/idea, you're welcome to. But unfortunately this isn't the way I think multidevice should be done, so unless you're also planning to open a pull request with these changes, I'm going to close this issue.

[jackzhp]

How to reopen this?
"the same pubkey"? Yes, same Onion_Friend to be mapped to several DHT public key（each for one device and each with one Crypto_Connection）.
Each ToxID corresponds to one Onion_Friend, and its DHT_Friend will change all the time even on one single device. Before support multiple devices, one Onion_Friend is corresponds to one DHT_Friend since only one DHT_Friend is in effect.
Now we want multiple devices, means one Onion_Friend should be mapped to multiple DHT_Friends with multiple DHT_Friends in effect.

The ultimate goal is to map one same public key (Onion_Friend) to serveral DHT_Friends.

One user with multiple devices means one Onion_Friend with multiple DHT_Friend.
Hence, same Onion_Friend public key, but different DHT_Friend public key.

And furthermore,
for 0x9C message, its current format: 0x9C + tsSeconds8 + pkDHTsender32+nodes
I would like to suggest new format:
new format
0x9C + tsSeconds8 + 0xFF + type1 + ...
when type1==0
0x9C + tsSeconds8 + 0xFF + type1(0x00) + deviceID + epkDHTsender + nodes

[GrayHatter]

I'm not going to reopen this. Using the same keypair across multiple devices is bad security. Any pull request or idea that shares the same key across devices isn't acceptable.

…

On August 12, 2018 8:22:12 PM PDT, jackiszhp ***@***.***> wrote: How to reopen this? "the same pubkey"? Yes, same Onion_Friend to be mapped to several DHT public key（each for one device and each with one Crypto_Connection）. Each ToxID corresponds to one Onion_Friend, and its DHT_Friend will change all the time even on one single device. Before support multiple devices, one Onion_Friend is corresponds to one DHT_Friend since only one DHT_Friend is in effect. Now we want multiple devices, means one Onion_Friend should be mapped to multiple DHT_Friends with multiple DHT_Friends in effect. The ultimate goal is to map one same public key (Onion_Friend) to serveral DHT_Friends. One user with multiple devices means one Onion_Friend with multiple DHT_Friend. Hence, same Onion_Friend public key, but different DHT_Friend public key. And furthermore, for 0x9C message, its current format: 0x9C + tsSeconds8 + pkDHTsender32+nodes I would like to suggest new format: new format 0x9C + tsSeconds8 + 0xFF + type1 + ... when type1==0 0x9C + tsSeconds8 + 0xFF + type1(0x00) + deviceID + epkDHTsender + nodes -- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #1650 (comment)

[jackzhp]

I am sorry. Totally misunderstanding! You misunderstood me!
Different devices should always use different keys! And which is delivered through 0x9C message.
The same keypair is for the same user ID, it is the same user over multiple devices! 0x83, 0x84, 0x85, 0x86 messages are talking about the userID (pkTargetReal), not the pubkey of a device. The pubkey of a device will be delivered through 0x9C message (of course will be wrapped into 0x85 & 0x86).

I totally agree with you, different devices should use different key pairs.

Jack

[GrayHatter]

You'll likely need to explain your idea in a lot more detail. If I did misunderstand how you want to go about this. Then I didn't understand any of the above.

Don't try to format it in pseudocode, instead just explain your idea very simply. Don't use variables, don't use hex numbers.

[jackzhp]

OK.
Since I do not know how familiar you are with the source code, let me put into two sections: section I --- single device, section II --- multidevices. Since before fully understands the mechanism of current single device, there is no point to talk about extension to multidevices.

suppose 2 users: user A with two devices(device_a1, device_a2), user X with 1 single device(device_x).

Section I --- single device.

device_x(of User X) announce the dhtpk which the user X wants to use. The user X should send this announce to user A. This announcement is the 0x9C message, which is wrapped into 0x85 message.
Now the detail: this 0x85 message is not sent to device_a(of User A), but to a point P which is "close" to PK_A. P then turns 0x85 message into 0x86 message and sends 0x86 message to user A.

Before device_x sends 0x85(0x9C) message to P, device_x asked P whether P can forward messages to user A. device_x asked P with message 0x83, P responded with message 0x84. P can respond with yes/no. If P responded yes, then user A must have had made the arrangement. the arrangement request is 0x83 message, and P responds with 0x84 message.

Now it is the time to investigate the structure/format of 0x83,0x84,0x85,0x86, and 0x9C messages in chronical order as follows.

User A arranges message forwarding with P with 0x83 message, user A has to send 0x83 message twice.
first time with pingid==0, 2nd time with right pindid. pindid is generated by P.
key parameter: the PK of user A(pkTargetReal, i.e. PK_A)
response 0x84: indicator==0 means not arranged, indicator==2 means arranged.

User X asks P whether P can forward messages to user A with 0x83 message
key parameter: the PK of user A(pkTargetReal)
response 0x84: indicator==0 means not able to forward, indicator==1 means being able to forward

user X announce its dhtpk with 0x9C message,
key parameter: dhtpk
for security reason, this message will be wrapped into 0x85 message.

User X sends 0x85 message to P
2 key parameters: PK of user A, X has to tell P where to forward
PK of user X, once user A received the message, the user A must know who is sending this.
By the way for security reason, 0x85 is wrapped into 0x80, 0x81, and 0x82(i.e. the onion) to reach P.

P processes 0x85 message, turns it to 0x86, and sends 0x86 to user A.
By the way 0x86 is sent to user A through 0x8C(0x8D(0x8E)) message.

Through the above process, the map between DHTPK and realPK(userID) is established.
When the user X wants to change DHTPK, the user X can go throught the above process again.

Section II -- multiple devices

In the section I, wheverver the userIDs take place, should be replaced for(with) userID and deviceID(a string will be good), and default single device is the case of empty deviceID. And wherever the dhtpk takes place, should be replaced for(with) dhtpk and deviceID.

With these replacement, the map between (deviceID,DHTPK) and (userID,deviceID) is established.

When user X asks P whether P can forward messages to user A, P responds with 0x84.
this 0x84 should tells P user X that P can forward messages to device_a1 and device_a2.

Hope what I presented is understandable.
Jack

[iphydf]

Hi Jack, can you formulate your proposal in the form of a design document? See https://toktok.ltd/designs for how to submit one for review. We can continue discussing the ideas on the pull request with the design doc.