GrayHatter
commented
6 years ago No, don't open a new issue for this idea.
Closed jackzhp closed 6 years ago
GrayHatter
commented
6 years ago No, don't open a new issue for this idea.
In order to support multidevices, I suggest to implement it in two phases.
Phase #1: change 0x83 & 0x84 messages, this modification makes effectively no change. I will explain later. This would allow smooth transition to phase #2. Phase #2: based on stage #1, add multiple devices support. change 0x83, 0x84, 0x85, 0x86 messages.
Multiple devices mean one real PK(userID/toxID) with several DHT(facade) device PKs. Each DHT(facade) PK corresponds to one device, they share the same real PK(userID/toxID). Different devices should always different keys(DHT_Friend)! And that PK is delivered through 0x9C message.
It is the same user over multiple devices! 0x83, 0x84, 0x85, 0x86 messages are talking about the same userID (pkTargetReal,Onion_Friend), not the pubkey of a device(DHT_Friend). The pubkey of a device will be delivered through 0x9C message (of course will be wrapped into 0x85 & 0x86).
Phase #1: To set up an onion entry(I prefer to call it to setup a worm hole): 0x83 + nonce24 + #0pk32 + encrypted120 while encrypted120 = pingid32 + pkTargetReal32 + pkWormHole32 + reqID8 + mac16. Current implementation #0pk32 and pkTargetReal32 are same, and because of this, wherever pkTargetReal32 is needed, #0pk32 is used. So let's change it to use pkTargetReal32 instead. To query an onion entry(to detect whether exists a worm hole to the specified target): 0x83 + nonce24 + #0pk32 + encrypted120 while encrypted120 = pingid32(0) + pkTargetReal32 + pkWormHole32(0) + reqID8 + mac16.
Phase #2: Replace pkTargetReal32 for epkTargetReal + deviceID This change applies to 0x83, 0x84, 0x85, 0x86 messages, as follows. for 0x83 message, its original format is shown in Phase #1, to support multidevices, its encrypted part could be redefined as encrypted =format1(0) + pingid32 + epkTargetReal + deviceID + pkWormHole32 + reqID8 + mac16 encrypted =format1(1) + epkTargetReal + deviceID + reqID8 + mac16 it is easy to distinguish new format from old format since old format is 120 bytes exactly.
for 0x84 message, its current format is 0x84 + reqID8 + nonce24 + encrypted while encrypted = indicator1 + pingid_O_pkWormHole32 + nodes + mac16 originally, indicator1 =0,1,2 are used. 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.
for 0x85 message, its current format is 0x85 + pkRecvReal32 + nonce24 + pkRandom32 + #0encrypted while #0encrypted = pkRealSender32+ #1encrypted + mac16
while #1encrypted = someData + mac16
in order to support multidevice pkRecvReal32 & pkRealSender32 should be replaced. I suggest the following new format 0x85 + 0xFF + type1 + .... 0xFF indicates new format is in effect, very unlikely pkRecvReal32 starts with 0xFF and type1==0 is defined 0x85 + 0xFF + type1(0) + epkRecvReal + deviceID + nonce24 + pkRandom32 + #0encrypted while #0encrypted = epkRealSender + deviceID + #1encrypted + mac16
for 0x86 message, it follows from 0x85 message.
or 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
the user ID, i.e. toxID has a public key inside, I hope to extend it a little bit. epkTargetReal is defined as follows: type1 + pk type1==0, pk is of sec256k1, epkTargetReal will be 1+33=34 bytes type1==1, pk is of curve25519, epkTargetReal will be 1+32=33 bytes type1==2..., 512bits pk might be used in the future. DeviceID is a string defined as follows: type1 + utf8bytes type1 means 1 byte to indicate how many bytes following. Device public key is delivered through 0x9C message.
any comments?
Jack