toxcore
toxcore copied to clipboard
irungentoo
Multiple device proposal
************************************************* multi device suppport *************************************************
////////////////////////////////////// //// P R O P O S A L //// //////////////////////////////////
What if a device gets stolen? It would be cool to be able to revoke it, without losing all your friends. But without a central server a perfect solution to this is not possible. Ideally, we'd have two keys. One master key for signing and revoking the other. However, I don't think that for the target audience exchanging two keys is a viable option. But what if there were a way of doing it user friendly....
Here my suggestion:
- Have separate decryption and signing keys in tox ID: master decryption key you need to decrypt onions. the private signing key should be in a safe place. Ideally locked away in a save place.
- Each device creates a different tox ID. (This one is called its device ID.)
- User creates his tox ID on one of the devices, (key for decryption + key for signing+nospam+checksum).
- User adds device ID's to that primary device.
- User either confirms on the respective device ( I think this is better than doing it automatically ) or
- User adds primary devices device ID on the secondary device
- User confirms secondary device's adding on primary ( if you want want it to be automatic, use a pin or so, similar to nospam) (the distinction of primary an secondary device need not be made, though)
- devices connect using their device ID's and then sync the device ids, friendslists, current session's past messages, and each new message once it is received.
- each device sends onions with its device id, and a cert that this device id is valid.
- once a friend is connected to one device, he sticks to it and does not round robin (i.e. as long as a responsive peer is found under that ip you do not change to new ip)
- if connection is lost, you retry the previous connection. If it fails you use onion and potentially end up on another device (new session).
You add a new device by simply creating a device ID, adding it to one of your previous devices. Devices connect to one another based on their device ID's if they are online, and friends do so too, so all friends can tell that I am using different devices.
Sessions are per-device and we try to stay on one device. If the user changes device and switches previous device off, a new session will be started. In case the user leaves the device on, he'll send from new device, this will initiate a new session. Old messages still received on previous device will be synced between the devices.
if a device gets lost/stolen, the user uses the tox id's master key to issue a revocation of that device' key and sends it to all other devices and all other friends.
each device should know which other devices of that user are online.
Device ID's need not be shared with your friends, only your one tox id.
Session authentication is done using the device key, but the DHT would not know how many devices I'm using, as onions are encrypted; friends would know.
The only means to decide where to send messages to should the current session. If there is no session yet, just take the first contact info you get for your peer. If it works fine, else try another. And if you receive from another device (another session) switch to that one entirely and drop the previous one.
PREPARATION Before being able to use a device you must add it to your user profile. That means, i ) you create a device ID and connect with DEVICE key to master. ii ) master gets notified about a DEVICE ADDING REQUEST, checks fingerprint, and accepts. iii) device's key (not ID) is signed by MASTER, and a revocation is created too. iv) slave device receives signature.
USAGE each device connects to the DHT a) with its device id in order to sync with the other devices b) with an ONION that contains a cert by MASTER (which friends do recognize) that device key is valid, plus the rest that it already contains now (temp key signed by device key, ip, port)
Adavantages:
- You can make sure that messages will arrive at the device you are communicating from, as it has its own id. Not half of the messages go to your phone, the other half to oyur computer at home.
- You can revoke lost devices, but other users will only learn of revocation, once they get the revocation notice.
- The master id can be kept in a save place. So even if your hpone was stolen and its password cracked (or the user had not even set one), it will be easy to ban that device without having to create a new user tox id.
Disadvantages:
- Minor: Your contacts could notice when you switch devices.
- The devices use two connection methods: one for friends, another for other shared devices in order to sync messages and friend lists. But implementationswise both be be almost identical, just the onion differs.
I don't know what it's worth, as nowdays, people always carry their phone or laptop with them, but this approach also allows for having time-imited keys that you can carry with you on a pendrive and use on untrusted third party computers. As those are untrusted, you would not be save from keyloggers or other spyware (so don't share super secret info), but you would not have to fear that your long-term keys get compromised, as you could easily create keys that are only valid for exactly the time of your trip.
************************************************* multi device support **************************************************
First, as a general comment: having a "master" device could be a flaw in some way, though it certainly makes it easier to think about.
On stray thought I had, I'm not entirely sure if it's relevant to the details of your proposal, is that we can extend the two checksum bytes to alias several devices to one key+nospam.
Currently, an address is verified as follows (pseudo code for https://github.com/irungentoo/toxcore/blob/master/toxcore/Messenger.c#L217..L221):
int check_addr(address, checkval) {
int checksum = compute_checksum(address);
return checksum ^ checkval == 0;
}
Instead what we could do is this:
ID creation stays as it currently is; other devices generate their own ID; to add a device to a previous ID, modify the orig-ID as follows (again pseudo code):
int new_device_id(origaddr, devicenum, *newaddr) {
ASSERT(1 <= devicenum < TOX_MAX_DEVICES);
int origchecksum = compute_checksum(origaddr); // get old checksum
int newchecksum = origchecksum ^ devicenum;
memcpy(newaddr, origaddr, PUBLICKKEYBYTES+NOSPAMBYTES);
memcpy(newaddr+PUBLICKKEYBYTES+NOSPAMBYTES, newchecksum, CHECKSUMBYTES);
}
Once each client confirms the association (possibly via some sort of signing as proposed above), then they each can broadcast to the onion that the newaddr is an alias for deviceaddr. It would require some new onion aliasing functionality, but any such proposal would require onion modifications anyways. How to actually communicate with any/all devices associated with an ID/person would need to be decided, but is independent of this aliasing proposal.
check_addr() would then be modified as follows:
int check_addr(address, checkval) {
int checksum = compute_checksum(address);
int devnum = checksum ^ checkval;
return 0 <= devnum && devnum < TOX_MAX_DEVICES;
/* The usefulness of the checksum for error checking would decrease from 16 bits to
2^16/TOX_MAX_DEVICES. If that's 16 though, quite a reasonable number, then
we still get 12 bits of safety from the checksum. */
}
I believe this might be able to avoid the usage of separate keys, which would be a fairly major overhaul of the entire design of Tox, whereas this can be done on top of how things already work.
After introducing Tox to a friend of mine, he forgot to copy his private tox data from his notebook to this home pc. So, we could not chat with each other via Tox.
I guess this is issue should provide a solution for that.
Not that I have a deep understanding of all that need to be done here, but from a users point of view, I would favor the following solution:
- He could create another key on his home pc. Give me his Tox ID and I can add him now.
- Later, when the time has come, he could join those two accounts by exchanging a common secret
- Accounts later be disjoined (by either account) again e.g. if the device is lost
join = in the sense of linking, not in the sense of replacing by a master account, the link can then be removed afterwards.
Does this makes sense?
@srkunze no it doesn't make sense, not from technical side. Please, you, and anyone else who wants to voice their opinions/suggestions read at least what already exists on the topic: https://github.com/Quoturnix/ProjectTox-Core/wiki/Multiple-devices
@srkunze Yes, this user experience would be possible, except for not having a master. Though when he forgot, as you say, you'd have to add his new key like he was a new friend. Only later the association with his previous key is made and only then, that previous key authenticates the latter.So except for revoking it latre, i don't se much use in this scenario. In the normal case you will want to add a friend only once. So there is a need for a master, otherwise you cannot revoke a stolen device' key. Without a master, your friend would have to save all of your device keys and after 'unlinking' them would not know which is the authentic you.
I came up with something similar (albeit much less deatiled): https://gist.github.com/sevcsik/18768b66b07eacbea522
The main differences are:
- There is no dedicated master device
- The master ID is always used by the node the user is currently using
- If there is two-way communication, participants connect directly
- To the other participant, the whole thing is transparent - it only sees that the other node has disconnected and reconnected again
Cons:
- Overhead when changing clients
- Every client has the master ID - if a device is compromised, and the toxfile is not encrypted, there's no way to revoke it. But that applies to having a single client too.
Personally i like the ideas involving master clients, especially for what it can do for mobile battery life.
If we are going to continue to sell Tox as a security conscious option for chatting any proposal that doesn't allow for device revocation is the wrong one. Bonus points for revocation being a 2way thing where we can tell the device to nuke it's logs and received files.
Personally i like the ideas involving master clients, especially for what it can do for mobile battery life.
I am sorry but I do not understand. What do both have to do with each other?
Back when we first started arguing about how to do multiple devices TCP wasn't done. UDP on mobile is the worst thing for battery. So having a master client that receives all your messages and maintains your online presence allowed your mobile device to stay in deep sleep. Your mobile device just needs to ping say your NAS or VPS once in a while to check for messages.
TCP works pretty well now so this means less they it used to.
Altough having a master device would solve a lot of issues, I wouldn't make it mandatory to have multiple devices synchronized. That would make it quite hard (probably not even worth trying) to use for the average user, and I think it also goes against the p2p nature of Tox to have a sync server to keep track of my devices (whether I run it on my desktop or on a VPS).
Probably power users would have an always connected client anyway (to work around offline messaging), but in my opinion we shouldn't rely on that practice to make multiple devices work.
On Thu, Mar 5, 2015 at 3:18 PM weedy [email protected] wrote:
Back when we first started arguing about how to do multiple devices TCP wasn't done. UDP on mobile is the worst thing for battery. So having a master client that receives all your messages and maintains your online presence allowed your mobile device to stay in deep sleep. Your mobile device just needs to ping say your NAS or VPS once in a while to check for messages.
TCP works pretty well now so this means less they it used to.
— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1100#issuecomment-77370394.
Well, I thought when people used the word "master client" they talked about the logical linking between master and slave clients.
NOT physical linking. So, the master being online all the time is an absolute no go.
I would say, having a master client being online when REGISTERING a slave client might be viable solution.
However, the best approach would be if people can generate something like an activation code to link secondary devices to the master key wthin a pre-defined period of time (24 hours or user-defined).
Ah, so you mean "master client" as a way to revoke access to lost devices? That's ok, I thought you're talking about a way to synchronize clients.
On Thu, Mar 5, 2015 at 5:16 PM Sven R. Kunze [email protected] wrote:
I would say, having a master client being online when REGISTERING a slave client might be viable solution.
However, the best approach would be if people can generate something like an activation code to link secondary devices to the master key wthin a pre-defined period of time (24 hours or user-defined).
— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1100#issuecomment-77393815.
I see. There are different use-cases, which require means.
Synchronize clients should of course working (after registering each other) when at least two of them are online.
So, I can imagine a setup where my desktop PC is used for managing secondary devices (add, remove, tablet, smartphone). However, I see no reason to startup my desktop PC just to have the tablet and the smartphone synchronize with each other.
People should be able to choose when they want to sync: on wifi, on mobile.
On 2015-03-05 09:18, weedy wrote:
Back when we first started arguing about how to do multiple devices TCP wasn't done. UDP on mobile is the worst thing for battery. So having a master client that receives all your messages and maintains your online presence allowed your mobile device to stay in deep sleep. Your mobile device just needs to ping say your NAS or VPS once in a while to check for messages.
TCP works pretty well now so this means less they it used to.
Reply to this email directly or view it on GitHub [1].
Links:
[1] https://github.com/irungentoo/toxcore/issues/1100#issuecomment-77370394 This is great, I would love to use this, but normal people won't be able to understand this, nor will they use it. Maybe it should be something hidden in settings that only power users would be able to fiddle with?
Maybe it should be something hidden in settings that only power users would be able to fiddle with?
I agree. Sane defaults for the Average Joe, options for the power users.
Just a faint question: when is this considered to be implemented? duck away
@srkunze : 1) there are many things that are being worked on, not everything can be done at the same time (currently new group chats and a new api are being worked on), and 2) it is not even decided yet which approach will be taken for multi device support. There are several ways to do it. The one above has the disadvantage that it would probably almost double the length of a tox id. (You need separate signing and encryption keys, i.e. two keys (no matter how many clients you use), such that each client can decrypt the onion and connect to peers, while only master key can add and revoke own clients. It would be transparent for the user, but still a longer id. Master only signs the client pk's. So master need not be online neither for syncing nor for telling your friends about the new clients you added. In fact, master NEVER needs to be online, it doesn't even need to be any client's main id.
When I was talking about master/slave I was speaking from a "power user" point of view. So for me my master would be always on. That said....
For the average user it makes little sense to make "always on" a hard requirement. Or even to make master/slave the default config. Anonymous TCP relays should work just fine. It just helps with things like mobile power usage or say disk space. I could ask my phone to only keep the last 6 months/500MB of history/media on disk. My master client can hold the complete copy of my history.
My house could have a power outage while downtown on 3G. I need to fall back to TCP or UDP in the case. And sync will happen at a later time (and probably over wifi). Also note, in my imaginary world of master/slave even if the master is up I don't see a reason why the clients can't directly talk to each other. If someone wants to talk to me I would think they would send a message to TOXID. At which point my NAS answers in place of my phone that it has received the message, and maybe my PC which also happens to be online answers that it received it (my PC doesn't care about power/bandwidth so it is in normal UDP mode using my "master" only for history sync). Now my friend knows TOXID:1234 and TOXID:5678 are online and will send to both until I reply at which point it will latch on to that client. History sync happens between TOXID:1234 and TOX ID:5678 at some heartbeat interval transparent to my friend. At some later point I pick up my phone and open tox. It is probably in sync or near sync with my desktop. My friend will get a message from TOXID:1234 (instead of TOXID:9012 because my phone is proxied through my master/relay) and swap over to sending directly to master. Now my PC is the one that receives history updates.
So uhh some requirements I guess.
- Master MUST be online to link slaves. Something along the lines of telling all devices/friends that TOXID:something is me. Whatsapp already does this.
- Master MUST be able to unlink slaves. Something along the lines of telling all devices/friends that TOXID:something is now bad.
- Clients MUST have side channel direct connection for syncing approved devices, history, friend lists, media, whatever else, This probably skips the Tox network most of the time unless a client is behind NAT and we use UDP.
- Clients MUST support normal UDP connections
- Clients CAN support TCP relays
- Clients CAN relay for other clients. This is more of a private proxy then the public TCP relay. It can become interesting when we think about 3G vs a home connection. Maybe in my mobile client I've selected "Don't download files over 512KiB on 3G" but I also selected "Always accept files from friends". Since I'm using another client as a proxy my phone should tell the proxy to accept all transfers, but it also won't immediately ask the proxy to forward the larger files at this time.
- Private relays CAN be the master. Maybe my desktop is the master (and thus has all my history) and my NAS is just a relay(very little or no history). Maybe my NAS is both the master and the relay and my desktop is a "dumb" client.
- Clients MUST fall back gracefully to standalone operation. The relay might have a power outage or something and we need to keep going. At some point it might come back and we need to push&pull history. While it's gone we should try and ping other devices on our own. and keep them in sync when possible.
There's more things I should list but I'm drawing a blank right now. But this should give you an idea what kinds of problems or configurations we could design for.
Tox is P2P, no version of multiple devices is going to be easy. And mobile has very real constraints we need to balance.
@aaannndddyyy Thanks for the detailed explanation. :)
I manage some projects myself and I am a programmer, too; though here I am just a whining user. Thus, I know that the resources are limited but I was just curious about when we might expect to see this feature.
@srkunze I think, generally speaking, multidevice is relatively high priority. After the api change and maybe the groupchats. But I am not actively involved in the project except for contributing some ideas and feedback. (I have never written a single C program). Therefore, I cannot provide even an approximate timeframe for it. Maybe someone else can. But again, it might be a totally different approach to multi device that will be chosen.