From 146a54ff7e19467c3d3ff501a38f00a59ba0f46e Mon Sep 17 00:00:00 2001 From: emdee Date: Sat, 15 Oct 2022 10:21:23 +0000 Subject: [PATCH] Tox over Tor --- DDosSmallNumberOfBSNodes.md | 118 +++--- GroupOfDevicesPOC.md | 24 +- Home.md | 64 +-- MultiDeviceAnnouncementsPOC.md | 686 ++++++++++++++++---------------- QToxGreen.md | 96 ++--- SecurityVulnerabilities.md | 30 +- ToxAndTorInChinaAndIran.md | 169 ++++---- ToxComparedWithOtherIm.md | 134 +++---- ToxMultiDevice.md | 636 ++++++++++++++--------------- ToxNetworkResilience.md | 2 +- UseGroupPasswordThroughAKDF.md | 12 +- VulnerabilitiesInTheToxOnion.md | 18 +- _Footer.md | 2 +- 13 files changed, 1003 insertions(+), 988 deletions(-) diff --git a/DDosSmallNumberOfBSNodes.md b/DDosSmallNumberOfBSNodes.md index 79110a2..97bccfa 100644 --- a/DDosSmallNumberOfBSNodes.md +++ b/DDosSmallNumberOfBSNodes.md @@ -1,59 +1,59 @@ -Previous: [[SecurityVulnerabilities]] - -By design, Tox relies on a small number of BS nodes. As the network -is now, the number of nodes is very small, and all well known. So Tox -is vulnerable to being completely taken down by blocking a small -number of nodes. - -The same problem, to a lesser extent affects Tor, although they have a -few thousand nodes. Doing the best we can with what we have, we can -take advantage of something from libtoxcore: the ```tcp_server slot```. -It is supported by most clients like toxic or toxygen. - -So this is what is proposed: - -1. Fix libtoxcore to be able to accept .onion addresses for BS nodes, -or test the workarounds: see [[ToxAndTorInChinaAndIran]]. - -2. All BS node operators are asked to also run a Tor client (not exit node), -in addition to running their node. We put together easy-to-follow instructions -on how to download/configure/run Tor. There are no risks to the BS operator -from running a Tor client (not exit node), and the overhead in negligible. -The onion server is a 127.0.0.1 service, so cannot be seen by your ISP. -Your service is on the opennet anyway so an onion is just another access method. -So we get dozens of Tor onion nodes running quickly. - -3. All Tor Tox client users are asked to also configure their Tox client to -use ```--tcp_server``` with a random port, and configure their Tor client -(not exit node) to provide that ```tcp_server``` as an onion accessible relay, -in addition to running the normal Tor. We put together easy-to-follow -instructions on how to configure Tor to serve that ```tcp_server``` as an onion. -There are no risks to the user as he's already running a Tor client -(not exit node), and the overhead in the Tox client in negligible. -The tcp_server is a 127.0.0.1 service, so cannot be seen by your ISP. -So we get a tcp_server extra for every Tor user. That scales well. - -4. Modify Tox clients to detect if they are behind Tor and on their homepage -or splash screen ask them to run a ```tcp_server```. - -5. Improve the client documentation on how to run Tox over Tor, -particularly for Android users: how to download Orbot from - (preferred over Srewgle Play) and configure them. -Tell them to try first running Orbot and a browser that works with it, -and test out if their mobile to see if they can run Tor. The Tor devs are actively -playing cat and mouse with Iran and have other tricks if regular Tor fails. - -6. Improve our ability to monitor network performance, including TCP relays, -so we can detect if anyone is attacking the network. - -PS: Trying make it easy to package and run a BS node in places like -Iran is going about it in the wrong way; I doubt running a BS node in -Iran is healthy thing to do. Get them onto Tor, and improve service over Tor. -Much better to get all of our BS nodes to run an onion service so -there is good availability and redundancy, and fix the minor problems -needed for Tox to work with onion BS nodes. - - - - - +Previous: [[SecurityVulnerabilities]] + +By design, Tox relies on a small number of BS nodes. As the network +is now, the number of nodes is very small, and all well known. So Tox +is vulnerable to being completely taken down by blocking a small +number of nodes. + +The same problem, to a lesser extent affects Tor, although they have a +few thousand nodes. Doing the best we can with what we have, we can +take advantage of something from libtoxcore: the ```tcp_server slot```. +It is supported by most clients like toxic or toxygen. + +So this is what is proposed: + +1. Fix libtoxcore to be able to accept .onion addresses for BS nodes, +or test the workarounds: see [[ToxAndTorInChinaAndIran]]. + +2. All BS node operators are asked to also run a Tor client (not exit node), +in addition to running their node. We put together easy-to-follow instructions +on how to download/configure/run Tor. There are no risks to the BS operator +from running a Tor client (not exit node), and the overhead in negligible. +The onion server is a 127.0.0.1 service, so cannot be seen by your ISP. +Your service is on the opennet anyway so an onion is just another access method. +So we get dozens of Tor onion nodes running quickly. + +3. All Tor Tox client users are asked to also configure their Tox client to +use ```--tcp_server``` with a random port, and configure their Tor client +(not exit node) to provide that ```tcp_server``` as an onion accessible relay, +in addition to running the normal Tor. We put together easy-to-follow +instructions on how to configure Tor to serve that ```tcp_server``` as an onion. +There are no risks to the user as he's already running a Tor client +(not exit node), and the overhead in the Tox client in negligible. +The tcp_server is a 127.0.0.1 service, so cannot be seen by your ISP. +So we get a tcp_server extra for every Tor user. That scales well. + +4. Modify Tox clients to detect if they are behind Tor and on their homepage +or splash screen ask them to run a ```tcp_server```. + +5. Improve the client documentation on how to run Tox over Tor, +particularly for Android users: how to download Orbot from + (preferred over Srewgle Play) and configure them. +Tell them to try first running Orbot and a browser that works with it, +and test out if their mobile to see if they can run Tor. The Tor devs are actively +playing cat and mouse with Iran and have other tricks if regular Tor fails. + +6. Improve our ability to monitor network performance, including TCP relays, +so we can detect if anyone is attacking the network. + +PS: Trying make it easy to package and run a BS node in places like +Iran is going about it in the wrong way; I doubt running a BS node in +Iran is healthy thing to do. Get them onto Tor, and improve service over Tor. +Much better to get all of our BS nodes to run an onion service so +there is good availability and redundancy, and fix the minor problems +needed for Tox to work with onion BS nodes. + + + + + diff --git a/GroupOfDevicesPOC.md b/GroupOfDevicesPOC.md index 9e720a7..c3237e7 100644 --- a/GroupOfDevicesPOC.md +++ b/GroupOfDevicesPOC.md @@ -1,12 +1,12 @@ -Previous: [[Home]] - -## Group Of Devices POC - -One way to address the multi-device problem is to add the multiple devices of a person into a NGC group. - -It may not scale well because messaging is sent to all devices of all users; -a single active user approach would be more efficient. - -And it wouldn't work for groups very well as a group-of-devices can -not be a member of an NGC group. - +Previous: [[Home]] + +## Group Of Devices POC + +One way to address the multi-device problem is to add the multiple devices of a person into a NGC group. + +It may not scale well because messaging is sent to all devices of all users; +a single active user approach would be more efficient. + +And it wouldn't work for groups very well as a group-of-devices can +not be a member of an NGC group. + diff --git a/Home.md b/Home.md index 1fe2199..4a3a6f0 100644 --- a/Home.md +++ b/Home.md @@ -1,32 +1,32 @@ -# Welcome to the Wiki. - -What I am noticing is that there is no notion of a Tox Improvement -Proposal(TIP), so ideas and vulnerabilities get forgotten in -abandonned PRs in abandoned repos, or ignored issues. - -I suggested wiki.tox.chat as a place to identify and prioritize TIPs -but maybe we can elaborate POCs here. I want to "argue" it out to get -to the "best" proposal so work so work can get going on a trial -version. developers who know the key exchange mechanisms can bring a -lot of the existing codebase to bear on this problem, and resolve -wrinkles in the concepts. - -### Multi-Device DHT announcements: - -* [[MultiDevice Announcements POC]] -* [[GroupOfDevicesPOC]] -* Original TokTok ToxMultiDevice: [[ToxMultiDevice]] - -### Network Resilience - -* [[ToxNetworkResilience]] - -### Security - -* [[SecurityVulnerabilities]]: - -** [[UseGroupPasswordThroughAKDF]] -** [[VulnerabilitiesInTheToxOnion]] -** [[DDosSmallNumberOfBSNodes]] - - +# Welcome to the Wiki. + +What I am noticing is that there is no notion of a Tox Improvement +Proposal(TIP), so ideas and vulnerabilities get forgotten in +abandonned PRs in abandoned repos, or ignored issues. + +I suggested wiki.tox.chat as a place to identify and prioritize TIPs +but maybe we can elaborate POCs here. I want to "argue" it out to get +to the "best" proposal so work so work can get going on a trial +version. developers who know the key exchange mechanisms can bring a +lot of the existing codebase to bear on this problem, and resolve +wrinkles in the concepts. + +### Multi-Device DHT announcements: + +* [[MultiDevice Announcements POC]] +* [[GroupOfDevicesPOC]] +* Original TokTok ToxMultiDevice: [[ToxMultiDevice]] + +### Network Resilience + +* [[ToxNetworkResilience]] + +### Security + +* [[SecurityVulnerabilities]]: + +** [[UseGroupPasswordThroughAKDF]] +** [[VulnerabilitiesInTheToxOnion]] +** [[DDosSmallNumberOfBSNodes]] + + diff --git a/MultiDeviceAnnouncementsPOC.md b/MultiDeviceAnnouncementsPOC.md index e7d98f0..8815aaa 100644 --- a/MultiDeviceAnnouncementsPOC.md +++ b/MultiDeviceAnnouncementsPOC.md @@ -1,343 +1,343 @@ -Previous: [[Home]] - -## We need to solve the usage of Tox with multiple devices. - -This proof-of-concept (POC) is based on the premise that solving the -usage of Tox with multiple devices is an urgent problem, as anyone -with mobiles runs into it, and all the competition software deals with it. -MultiDevice is much easier in centralized systems and our decentalization -is why it's hard for us; if we make it, we make be the first ever! - -**Woke Warning:** gender specific, non-android/furry friendly grammar -is used throughout. - -The idea here is to address one simple usecase: a person can have -multiple devices and he wants one device to be "active" at any given time. -So he pushes so kind of announcement of what device he is currently -using so that others can communicate to the device he is currently using. - -The POC ignores the problem of history sync that this creates. -Others can address that later perhaps with tools like rsync. - -## Background - -When it comes to multi-device support, at the present time we are -lagging behind well-known centralized messenger systems. A few -examples are Google Hangouts, Facebook Messenger, and Skype. Every one -of these syncs messages to every device which connects to their -network. If you need an address, number, or entire friend list it’s a -simple login away. [[ToxMultiDevice]] - -Not the goal of this project but an important benefit, Multi-Device -support would solve some of the issues sharing a ToxID: it would allow -the clients to connect with mobile devices (NFC, QR codes, other) and -be available anywhere. - -## First Steps - -The idea is to firstly define a PersonaID, much like a ToxPk that -stays permanent across his devices, and maps the Person to the active ToxPk. - -So the first step is to extend all library code and all clients to -work with PersonaIDs as well as ToxPks. The PersonaIDs would be client -facing, and the ToxPk code would be for internal access. A simple -implementation would be duplicating all code calls that deals with -ToxPks to have a layer of calls on top that take the PersonaID and -consult a table that contains the active ToxPk, and then calls the -ToxPk function. - -For the sake of argument, let's say that the table is initially -populated with all the existing ToxPks by deriving a default PersonaID -ToxID by a simple method: the default table contains a PersonaID that -is the ToxPk (identity table). - -So we can add this layer of PersonaID->ToxPk mapping to the library -and all clients right away with no breakage. In time, the clients will -move to showing the PersonaID not the ToxPk as the primary client-facing ID, -and extend the clients with the ability to see the table of Personae -> -ToxPks (but maybe not change the entries), and the active ToxPk for -each PersonaID. - -More concretely, the PersonaID mapping table would be like a dictionary -with 2 (or more) types of entries; before the arrival of a blob update, -the table is by default (assuming JSON) -``` -{"Pk1": "Pk1", - "Pk2": "Pk2", - ...} -``` -So we could get the whole network switched over to accommodating PersonaIDs -with no breakage. After the arrival of a blob to update the table, -the PersonaID is an ordered dictionary mapping to a list of device PKs: -``` -{"Pk1": "Pe1", - "Pe1": ["Pe1k1", "Pe1k2", ...], - "Pk2": "Pk2", - ...} -``` -or better still, associated ordered dictionary mapping to a dictionary with -```devices``` entry with a dictionary using nicknames: -``` -{"Pk1": "Pe1", - "Pe1": {"devices": { - "Device1Nick": "Pe1k1", - "Device2Nick": "Pe1k2", ...} - }, - "Pk2": "Pk2", - ...} -``` - -where: - * ```Pk1``` is the PK of user1, - * ```Pe1``` is the PersonaID of user1, which could be the public signing key of user1. - * ```["Pe1k1", "Pe1k2", ...]``` are the PKs of each of the devices of user1, - delivered in a blob signed by ```Pe1`` - -Richer formats for the table are obviously possible, but we want to -maintain a structure that foresees this table being managed by a -keyring manager like ```keepassxc```. - -## MultiDevice Announcements Push - -So if we modify the library and clients as described above, 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 client 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 Persona storage. For the sake of this POC: - -1. the storage file could be JSON, possibly encrypted with ToxESave, or - -2. it could be a files in a ```Personae``` directory with files saved -in JSON or YAML, like we do with avatars, with the filename being named -```PersonaID.json```. - -Again, we want to maintain a structure that foresees this table being -managed by a keyring manager like ```keepassxc```. It would not be -saved in a profile, as this table spans multiple profiles. - -Let's say we have a friend, and we know his ToxPk. We initially derive -his PersonaID by setting it to the friend's public key - the entry in -the table is a string. - -We will call "a blob" the information that will update our PersonaID -mapping to his active ToxID that is pushed to clients. We want to -watch the blob flow for changes. So what is the blob flow of information? - -1. If a blob is small we can base64 encode it and stick it in his status message, - -2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a sub-directory called ```Personae```, and handle updates the way we do avatars. - -3. We might push it as a DHT announcement. - -Some clients may let the user decide whether of not to accept a blob -update when it arrives. - -## MultiDevice Announcements Blob - -So what is the blob of information that is pushed? - -It has these characteristics: - -1. It has 3 things - a name and a payload, and a NaCl signature. - -2. It is small - 1K to 4K in size. - -3) As we will need a NaCl signing keypair in order to sign the payload, -the name, (PersonaID) can be the public key of the signing keypair - -32 bytes or 64 hex chars. - -4. If we push the blob info by DHT announcements, 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. If we push it like -avatars, then it can be pushed once at start and subsequently on any changes. - -5) It might be encrypted so that the contents can not be seen in transit, -but if the push mechanism is within Tox, it would be unnecessary. - -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. The public key -of the signing keypair can be used as the PersonaID. If a secret is used -as the seed of the signing keypair, then the generated keypair is reproducible. - -If we use DHT announcements, 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 -friends. 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. This set of ToxPks could be keys -that open the encrypted blob. Anyone who already has a ToxPk of the -Persona could open the blob to get the update. Hence this encryption -is different from most Tox encryption in that multiple keys can open -it - like a multi-key Vera/True/dmwrapper container. But it might be -enough for the blob to be signed, and that would be a good starting -point - add encryption later if needed. - -The public signing key could be put into the status message field of -each Person, and if each user put the same signature public key as the -status message on each of his devices, then that signing 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. - -I had assumed we would have to use the DHT to deal with decentralization. -But this POC makes me think we can use the toxcore status_message -and avatar_files code to do it without the DHT, at least to Friends. -So let's say for now to focus this discussion, we will ignore DHT announcements. - -1. Set your status message to be the signing public key and push the blob by some means like avatars to Friends, or - -2. It can be pushed as a status message. If we 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. - -3. If the blog.gz is less than 1000 chars, could it fit in a QR code? - -In fact we could do #2 first to get things going, and then do #1, -which is more changes to the code, although a lot of the code could be -morphed from the avatar code. Or you could push a blob as a file if -it got too big for a status message. - -The same blob would be on each of a Person's devices. - -### Use the status message if less than 1007 bytes - -With the signature and the public key, this should leave room for at -least 12 devices in less than 1007 bytes, compressed and base64 -encoded. With 1007 bytes with the signature and signing key, and -nicknames of 12 bytes it will take about 16 -devices: ```1007-128-64-2/(32+6+12) = 16``` - -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, -unless they had the signing public key independently (perhaps using -/sendfile). But perhaps that's good. Clients could watch status -message changes easily using the status_message callback. - -### It can be pushed as files like avatars amongst Friends - -All the avatar code could be repurposed to also handle blobs, with the -signing public key put into the Person's status message. Avatars are -simple file transfers; there is a WHOLE byte dedicated for "file_kind", -which means we can "just" add a new file_kind and use the exising file -transfer code. In the beginning the clients would not need to be able -to generate the blob - a simple Python script could do it outside the clients. - -Unknown for now is does the client have to send a Friend ```add -request``` to any new ToxPks found in the blob (new devices) to make -them active if the client has never seen the PK before? I assume yes. -If so then it complicates things a little as the blob might need to contain -ToxIDs. The code could accept either ToxPks or ToxIds, distinguishing -by length. Or you could just require that the Person already be a -Friend with that device before the information in the table was useable. - -(The blob might be a signed way of associating nicknames with Pks if -we use associated ordered dictionary mapping to a dictionary with nicknames.) - -The clients would manage this seamlessly 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. - -The generation and signing verification of the blobs could be done -outside of the clients in a utilty common to all clients. The clients -let a user push a blob whenever he wants - like when he changes devices. - -## MultiDevice Profiles - -In order for MultiDevice to work, we need to bootstrap a new devices from an -existing profile. If you just copy a profile from one device to the next it will not work as you cannot have 2 profiles with the same keys online at the same time. We could have a simple utility that rekeys a profile and creates a new ToxID, so that we could copy a profile and rekey it. Then the new client would push a new blob with the new device's PK, signed by the signing keypair which is independent of profiles. - -The profile rekey utility could also do other things at the same time, like edit the TCP_RELAYS section of the profile if desired. -See - -## 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. - -But we are left with as special problem with NGC groups. - -The code is assumed to have been modified to handle Personas and, at -first glance, NGC groups become groups of Personas. Each member of the -group is a Persona, and uses the table lookup to get the active ToxPk. - -But the group structure in the profile has a copy of the founder's -shared_state.founder_public_key (group_pack.c#L293) So if the profile -being copied onto a new device is the profile of the founder, then -this key would need to be updated too. - -Besides the group keypair in #L351-2 -* bin_pack_bin(bp, chat->chat_public_key, EXT_PUBLIC_KEY_SIZE); // 1 -* bin_pack_bin(bp, chat->chat_secret_key, EXT_SECRET_KEY_SIZE); // 2 - -The chat->chat_secret_key is all zeros, I assume in everyone but the founder's -profile. - -It seems also that self's group keypair are saved to the group: -* self_public_key #L353 -* self_secret_key #L354 - -Do these keys have to be updated with the new keypair of the new -profile? Or do you only copy the keys from the profile that was in -use when the Person first joined the group as a user - wrinkle. In -which case, the notion of the blob needs extending from just the -ToxPks and nicknames of each of the devices, to include the secret -keys of that Persona for each NGC group the Persona belongs to. - -In other words if I have 3 profiles with 3 nicks and 3 keypairs, and the -first profile had a GROUP section where I have a group_nick, could I copy -the GROUP section entirely into the other 2 profiles, and then be a member -of the NGC group known as group_nick when I used those profiles? If so, -the Persona should have dictionarys for each group, with -```group_nick```, ```self_public_key``` and ```self_secret_key``` in each. - -( Aside: I don't like the idea of keeping secret keys in profiles; they -should be managed by a keymanager. In a corporate setting, this will -be a requirement. ) - -There is a Python script to parse profiles that could be modified to rekey -group self entries at: https://git.plastiras.org/emdee/tox_profile - -## Future Directions - -If Personae identify which are your devices, it opens the possibility that -clients could treat incoming messages from one of your devices differently. -Instead of simply displaying the message in a window, the client might -examine the message to see if it is a command. So clients could build in, -for example a filebot, that responds to a set of commands if it's coming -from one of your devices. Automated file transfer, DoorSpy, history sync; -the possibilities are endless. - -## Summary - -The changes to the core are not large: -1. Change the status message callback to look for public signing keys -2. Change the status message callback to look for blobs as a first - implementation, and then later extend the avatar file transfer mechanism - to transfer blobs -3. Use the public signing keys to verify the blobs. This a NaCl call. -4. Store the blobs in a subdirectory, with their signature. -5. Use the blobs to populate the table, and designate one entry as active. -6. Wrap all the calls that use a PK to look in the table for the active PK. -7. Update the tables, if files are deleted from the ```Persona``` directory. - -All existing unmodified users would continue to work: no testnet required. - -Assuming the blobs were created by an independent stand alone utility, -the changes to the clients are not large: -1. Consult the mapping table and show it to the users. -2. Accept or reject new blob updates. -3. Redefine the notion of contacts to point to the PersonaID. -4. Add the ability to push a new blob to Friends, or perhaps selected Friends. - -Also we would want the Python script to keep profiles within a Persona in sync. -We need to resolve the questions about having the same groups Personae. +Previous: [[Home]] + +## We need to solve the usage of Tox with multiple devices. + +This proof-of-concept (POC) is based on the premise that solving the +usage of Tox with multiple devices is an urgent problem, as anyone +with mobiles runs into it, and all the competition software deals with it. +MultiDevice is much easier in centralized systems and our decentalization +is why it's hard for us; if we make it, we make be the first ever! + +**Woke Warning:** gender specific, non-android/furry friendly grammar +is used throughout. + +The idea here is to address one simple usecase: a person can have +multiple devices and he wants one device to be "active" at any given time. +So he pushes so kind of announcement of what device he is currently +using so that others can communicate to the device he is currently using. + +The POC ignores the problem of history sync that this creates. +Others can address that later perhaps with tools like rsync. + +## Background + +When it comes to multi-device support, at the present time we are +lagging behind well-known centralized messenger systems. A few +examples are Google Hangouts, Facebook Messenger, and Skype. Every one +of these syncs messages to every device which connects to their +network. If you need an address, number, or entire friend list it’s a +simple login away. [[ToxMultiDevice]] + +Not the goal of this project but an important benefit, Multi-Device +support would solve some of the issues sharing a ToxID: it would allow +the clients to connect with mobile devices (NFC, QR codes, other) and +be available anywhere. + +## First Steps + +The idea is to firstly define a PersonaID, much like a ToxPk that +stays permanent across his devices, and maps the Person to the active ToxPk. + +So the first step is to extend all library code and all clients to +work with PersonaIDs as well as ToxPks. The PersonaIDs would be client +facing, and the ToxPk code would be for internal access. A simple +implementation would be duplicating all code calls that deals with +ToxPks to have a layer of calls on top that take the PersonaID and +consult a table that contains the active ToxPk, and then calls the +ToxPk function. + +For the sake of argument, let's say that the table is initially +populated with all the existing ToxPks by deriving a default PersonaID +ToxID by a simple method: the default table contains a PersonaID that +is the ToxPk (identity table). + +So we can add this layer of PersonaID->ToxPk mapping to the library +and all clients right away with no breakage. In time, the clients will +move to showing the PersonaID not the ToxPk as the primary client-facing ID, +and extend the clients with the ability to see the table of Personae -> +ToxPks (but maybe not change the entries), and the active ToxPk for +each PersonaID. + +More concretely, the PersonaID mapping table would be like a dictionary +with 2 (or more) types of entries; before the arrival of a blob update, +the table is by default (assuming JSON) +``` +{"Pk1": "Pk1", + "Pk2": "Pk2", + ...} +``` +So we could get the whole network switched over to accommodating PersonaIDs +with no breakage. After the arrival of a blob to update the table, +the PersonaID is an ordered dictionary mapping to a list of device PKs: +``` +{"Pk1": "Pe1", + "Pe1": ["Pe1k1", "Pe1k2", ...], + "Pk2": "Pk2", + ...} +``` +or better still, associated ordered dictionary mapping to a dictionary with +```devices``` entry with a dictionary using nicknames: +``` +{"Pk1": "Pe1", + "Pe1": {"devices": { + "Device1Nick": "Pe1k1", + "Device2Nick": "Pe1k2", ...} + }, + "Pk2": "Pk2", + ...} +``` + +where: + * ```Pk1``` is the PK of user1, + * ```Pe1``` is the PersonaID of user1, which could be the public signing key of user1. + * ```["Pe1k1", "Pe1k2", ...]``` are the PKs of each of the devices of user1, + delivered in a blob signed by ```Pe1`` + +Richer formats for the table are obviously possible, but we want to +maintain a structure that foresees this table being managed by a +keyring manager like ```keepassxc```. + +## MultiDevice Announcements Push + +So if we modify the library and clients as described above, 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 client 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 Persona storage. For the sake of this POC: + +1. the storage file could be JSON, possibly encrypted with ToxESave, or + +2. it could be a files in a ```Personae``` directory with files saved +in JSON or YAML, like we do with avatars, with the filename being named +```PersonaID.json```. + +Again, we want to maintain a structure that foresees this table being +managed by a keyring manager like ```keepassxc```. It would not be +saved in a profile, as this table spans multiple profiles. + +Let's say we have a friend, and we know his ToxPk. We initially derive +his PersonaID by setting it to the friend's public key - the entry in +the table is a string. + +We will call "a blob" the information that will update our PersonaID +mapping to his active ToxID that is pushed to clients. We want to +watch the blob flow for changes. So what is the blob flow of information? + +1. If a blob is small we can base64 encode it and stick it in his status message, + +2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a sub-directory called ```Personae```, and handle updates the way we do avatars. + +3. We might push it as a DHT announcement. + +Some clients may let the user decide whether of not to accept a blob +update when it arrives. + +## MultiDevice Announcements Blob + +So what is the blob of information that is pushed? + +It has these characteristics: + +1. It has 3 things - a name and a payload, and a NaCl signature. + +2. It is small - 1K to 4K in size. + +3) As we will need a NaCl signing keypair in order to sign the payload, +the name, (PersonaID) can be the public key of the signing keypair - +32 bytes or 64 hex chars. + +4. If we push the blob info by DHT announcements, 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. If we push it like +avatars, then it can be pushed once at start and subsequently on any changes. + +5) It might be encrypted so that the contents can not be seen in transit, +but if the push mechanism is within Tox, it would be unnecessary. + +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. The public key +of the signing keypair can be used as the PersonaID. If a secret is used +as the seed of the signing keypair, then the generated keypair is reproducible. + +If we use DHT announcements, 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 +friends. 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. This set of ToxPks could be keys +that open the encrypted blob. Anyone who already has a ToxPk of the +Persona could open the blob to get the update. Hence this encryption +is different from most Tox encryption in that multiple keys can open +it - like a multi-key Vera/True/dmwrapper container. But it might be +enough for the blob to be signed, and that would be a good starting +point - add encryption later if needed. + +The public signing key could be put into the status message field of +each Person, and if each user put the same signature public key as the +status message on each of his devices, then that signing 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. + +I had assumed we would have to use the DHT to deal with decentralization. +But this POC makes me think we can use the toxcore status_message +and avatar_files code to do it without the DHT, at least to Friends. +So let's say for now to focus this discussion, we will ignore DHT announcements. + +1. Set your status message to be the signing public key and push the blob by some means like avatars to Friends, or + +2. It can be pushed as a status message. If we 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. + +3. If the blog.gz is less than 1000 chars, could it fit in a QR code? + +In fact we could do #2 first to get things going, and then do #1, +which is more changes to the code, although a lot of the code could be +morphed from the avatar code. Or you could push a blob as a file if +it got too big for a status message. + +The same blob would be on each of a Person's devices. + +### Use the status message if less than 1007 bytes + +With the signature and the public key, this should leave room for at +least 12 devices in less than 1007 bytes, compressed and base64 +encoded. With 1007 bytes with the signature and signing key, and +nicknames of 12 bytes it will take about 16 +devices: ```1007-128-64-2/(32+6+12) = 16``` + +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, +unless they had the signing public key independently (perhaps using +/sendfile). But perhaps that's good. Clients could watch status +message changes easily using the status_message callback. + +### It can be pushed as files like avatars amongst Friends + +All the avatar code could be repurposed to also handle blobs, with the +signing public key put into the Person's status message. Avatars are +simple file transfers; there is a WHOLE byte dedicated for "file_kind", +which means we can "just" add a new file_kind and use the exising file +transfer code. In the beginning the clients would not need to be able +to generate the blob - a simple Python script could do it outside the clients. + +Unknown for now is does the client have to send a Friend ```add +request``` to any new ToxPks found in the blob (new devices) to make +them active if the client has never seen the PK before? I assume yes. +If so then it complicates things a little as the blob might need to contain +ToxIDs. The code could accept either ToxPks or ToxIds, distinguishing +by length. Or you could just require that the Person already be a +Friend with that device before the information in the table was useable. + +(The blob might be a signed way of associating nicknames with Pks if +we use associated ordered dictionary mapping to a dictionary with nicknames.) + +The clients would manage this seamlessly 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. + +The generation and signing verification of the blobs could be done +outside of the clients in a utilty common to all clients. The clients +let a user push a blob whenever he wants - like when he changes devices. + +## MultiDevice Profiles + +In order for MultiDevice to work, we need to bootstrap a new devices from an +existing profile. If you just copy a profile from one device to the next it will not work as you cannot have 2 profiles with the same keys online at the same time. We could have a simple utility that rekeys a profile and creates a new ToxID, so that we could copy a profile and rekey it. Then the new client would push a new blob with the new device's PK, signed by the signing keypair which is independent of profiles. + +The profile rekey utility could also do other things at the same time, like edit the TCP_RELAYS section of the profile if desired. +See + +## 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. + +But we are left with as special problem with NGC groups. + +The code is assumed to have been modified to handle Personas and, at +first glance, NGC groups become groups of Personas. Each member of the +group is a Persona, and uses the table lookup to get the active ToxPk. + +But the group structure in the profile has a copy of the founder's +shared_state.founder_public_key (group_pack.c#L293) So if the profile +being copied onto a new device is the profile of the founder, then +this key would need to be updated too. + +Besides the group keypair in #L351-2 +* bin_pack_bin(bp, chat->chat_public_key, EXT_PUBLIC_KEY_SIZE); // 1 +* bin_pack_bin(bp, chat->chat_secret_key, EXT_SECRET_KEY_SIZE); // 2 + +The chat->chat_secret_key is all zeros, I assume in everyone but the founder's +profile. + +It seems also that self's group keypair are saved to the group: +* self_public_key #L353 +* self_secret_key #L354 + +Do these keys have to be updated with the new keypair of the new +profile? Or do you only copy the keys from the profile that was in +use when the Person first joined the group as a user - wrinkle. In +which case, the notion of the blob needs extending from just the +ToxPks and nicknames of each of the devices, to include the secret +keys of that Persona for each NGC group the Persona belongs to. + +In other words if I have 3 profiles with 3 nicks and 3 keypairs, and the +first profile had a GROUP section where I have a group_nick, could I copy +the GROUP section entirely into the other 2 profiles, and then be a member +of the NGC group known as group_nick when I used those profiles? If so, +the Persona should have dictionarys for each group, with +```group_nick```, ```self_public_key``` and ```self_secret_key``` in each. + +( Aside: I don't like the idea of keeping secret keys in profiles; they +should be managed by a keymanager. In a corporate setting, this will +be a requirement. ) + +There is a Python script to parse profiles that could be modified to rekey +group self entries at: https://git.plastiras.org/emdee/tox_profile + +## Future Directions + +If Personae identify which are your devices, it opens the possibility that +clients could treat incoming messages from one of your devices differently. +Instead of simply displaying the message in a window, the client might +examine the message to see if it is a command. So clients could build in, +for example a filebot, that responds to a set of commands if it's coming +from one of your devices. Automated file transfer, DoorSpy, history sync; +the possibilities are endless. + +## Summary + +The changes to the core are not large: +1. Change the status message callback to look for public signing keys +2. Change the status message callback to look for blobs as a first + implementation, and then later extend the avatar file transfer mechanism + to transfer blobs +3. Use the public signing keys to verify the blobs. This a NaCl call. +4. Store the blobs in a subdirectory, with their signature. +5. Use the blobs to populate the table, and designate one entry as active. +6. Wrap all the calls that use a PK to look in the table for the active PK. +7. Update the tables, if files are deleted from the ```Persona``` directory. + +All existing unmodified users would continue to work: no testnet required. + +Assuming the blobs were created by an independent stand alone utility, +the changes to the clients are not large: +1. Consult the mapping table and show it to the users. +2. Accept or reject new blob updates. +3. Redefine the notion of contacts to point to the PersonaID. +4. Add the ability to push a new blob to Friends, or perhaps selected Friends. + +Also we would want the Python script to keep profiles within a Persona in sync. +We need to resolve the questions about having the same groups Personae. diff --git a/QToxGreen.md b/QToxGreen.md index 05748f8..5e0af57 100644 --- a/QToxGreen.md +++ b/QToxGreen.md @@ -1,48 +1,48 @@ -Up: [[Home]] - - -# Anthony Bilinski - -## Zoominfo LinkedIn - -Works full time as: -> C Software Engineer & Open Source Project Application -> Developer & Firmware Maintainer & Developer at Avigilon - -* https://www.zoominfo.com/p/Anthony-Bilinski/628037601 -* https://ca.linkedin.com/in/anthony-bilinski-b4178611a (archive: https://archive.ph/X6Tsy ) -* https://www.zoominfo.com/p/Anthony-Bilinski/3246706849 - -So he's working on Open Source projects as his day job at Avigilon May 2016 - Sep 2021 - 5 years 5 months. Maybe qTox was his day job until Sept 2021? - -Avigilon is a video surveillance hardware and software company founded in 2004, went public on the VSE and was bought out by Motorolla. His zoominfo listing gives -```a***@curtiswright.com``` as his email. Curtiswright is a well know USGov contractor. He did an Internship at Curtis in 2014, so the @curtiswright email may not be current - an old zoominfo address. - -His boss and colleague on the zoominfo.com list both check out. His boss was a [well-known Security Industry professional](https://www.sdmmag.com/articles/100828-security-industry-mourns-the-loss-of-matthew-krebs) not based in Canada. - -## Website - -His web site no longer responds https://www.abilinski.com/ -It was just a one page pointing to a ToxId -* https://web.archive.org/web/20180825193239/https://www.abilinski.com/ - -His BS nodes no longer respond: -* tox.abilinski.com -* tox2.abilinski.com - -There is no github activity since July: -* https://github.com/qtox/qtox -* https://github.com/anthonybilinski - -## Funding - -Nothing on reddit.com in the last 6 months: -* https://www.reddit.com/user/Anthony_Bilinski - -Posted a [blog that announced he had a year's funding]( C Software Engineer & Open Source Project Application +> Developer & Firmware Maintainer & Developer at Avigilon + +* https://www.zoominfo.com/p/Anthony-Bilinski/628037601 +* https://ca.linkedin.com/in/anthony-bilinski-b4178611a (archive: https://archive.ph/X6Tsy ) +* https://www.zoominfo.com/p/Anthony-Bilinski/3246706849 + +So he's working on Open Source projects as his day job at Avigilon May 2016 - Sep 2021 - 5 years 5 months. Maybe qTox was his day job until Sept 2021? + +Avigilon is a video surveillance hardware and software company founded in 2004, went public on the VSE and was bought out by Motorolla. His zoominfo listing gives +```a***@curtiswright.com``` as his email. Curtiswright is a well know USGov contractor. He did an Internship at Curtis in 2014, so the @curtiswright email may not be current - an old zoominfo address. + +His boss and colleague on the zoominfo.com list both check out. His boss was a [well-known Security Industry professional](https://www.sdmmag.com/articles/100828-security-industry-mourns-the-loss-of-matthew-krebs) not based in Canada. + +## Website + +His web site no longer responds https://www.abilinski.com/ +It was just a one page pointing to a ToxId +* https://web.archive.org/web/20180825193239/https://www.abilinski.com/ + +His BS nodes no longer respond: +* tox.abilinski.com +* tox2.abilinski.com + +There is no github activity since July: +* https://github.com/qtox/qtox +* https://github.com/anthonybilinski + +## Funding + +Nothing on reddit.com in the last 6 months: +* https://www.reddit.com/user/Anthony_Bilinski + +Posted a [blog that announced he had a year's funding]( +Previous: [[Home]] + +* [[UseGroupPasswordThroughAKDF]] +* [[VulnerabilitiesInTheToxOnion]] +* [[DDosSmallNumberOfBSNodes]] +* Currently, toxcore uses onion routing in the process of establishing connections between friends, with the aim of obscuring their identities from third parties. However, this method does not achieve this goal. [This document describes a proposed replacement for onion routing.](https://github.com/zugz/tox-DHTAnnouncements/blob/master/DHTAnnouncements.md)This proposal is adapted from an original proposal by [grayhatter](https://wiki.cmdline.org/doku.php?id=dht:new_friend_finding). + + +##mCVEs: + +* [CVE-2018-25022](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25022) The Onion module in toxcore before 0.2.2 + +See also: [[ToxComparedWithOtherIm]] + +See also: diff --git a/ToxAndTorInChinaAndIran.md b/ToxAndTorInChinaAndIran.md index 5dbd73d..4e20acc 100644 --- a/ToxAndTorInChinaAndIran.md +++ b/ToxAndTorInChinaAndIran.md @@ -1,77 +1,92 @@ -Up: [[Home]] - -From: https://github.com/TokTok/c-toxcore/issues/419 - -I don't think indistinguishable message bytes and sizes are going to -make any difference when they are sent over a network of so few bootstrap nodes. -And anyone operating in a hostile environment is probably already -running Tox over Tor, which works well. - -Did the reports of blocking in China include blocking over Tor? Tor -itself has implemented pluggable transport mechanisms that are -continuously being improved, and these include ways to make the -traffic look like another protocol like HTTP or whatever: - - -So the best way to handle this may be to improve the documentation in -Tox of how to use Tor, and how to configure Tor to use pluggable transports (obfs4). -Whether or not you trust Tor (you can't trust Exit nodes 40% of the time) -they are the only things that work right now in e.g. Egypt or Iran. - -I also think the only way of getting a lot of resilience "cheaply" is -to encourage bootstrap node operators to also run a Tor client to serve -the BS node over Onionv3. This is the only way I can see dealing with the -fact that Tox is a network of so few bootstrap nodes. If the Tox nodebase was -improved to serve BS nodes, and OnionV3 relays, it would be much more resilient. -I'm assuming the adversaries cannot block .onion addresses within Tor. - -There is a way of configuring a Tor client to uniquely assign a -life-of-the-tor-instance IPv4 address from a predefined private range -(VirtualAddrNetworkIPv4) to each onion address it sees: -```AutomapHostsOnResolve 1```. So Tox could use OnionV3 BS nodes in a -properly configured Tor with just some properly configured BS hosts lists -(if enough BS nodes provided OnionV3 addresses). Then we could leave -the heavy lifting of the cat-and-mouse games of pluggable transports etc. -to Tor (or i2p), and not try to chase them ourselves. - -If you have such a list of onion addresses, the Tor user, who is running -a Tor instance anyway to connect with the Tox client, adds this to the -```/etc/tor/torrc``` -``` -VirtualAddrNetworkIPv4 172.16.0.0/12 -AutomapHostsOnResolve 1 -``` -Then with the list of onion addresses for BS nodes that are running Tox as OnionV3, -then you can use ```tor-resolve``` or ```tor-resolve -4``` to get the -good-for-you-only IP addresses of OnionV3 BS nodes in IPv4. So the Tox user -does this and puts these addresses into his ```DHTnodes.json``` and boostraps his -Tox client over Tor Onions. This works with libtoxcore is it is today, as long as -your client doesn't suffer from the dreaded deranged-hard-coded-bs syndrome. - -These steps would be automated by a simple bash or Python script, -perhaps a Python script wrapped into an exe for Windows. These addresses are -good for life of the Tor instance, and the script would need rerunning when Tor -is restarted. You can also get the IPv4 address of each Onion BS node, -(for-life-of-the-tor-instance which is usually long enough) -in Python using the Tor stem library. - -I've tried this but it's currently impossible to test as there is no equivalent -to the ```other/fun/bootstrap_node_info.py``` script for TCP connections. -For UDP you can send a packet of len 78 with the magic first bytes and get a -version and MOTD reply. Not so for TCP ( -in fact if you do send such a packet to the TCP it send the BS node into an -[infinite loop for which it neverrecovers](https://github.com/TokTok/c-toxcore/issues/2332)). -So we need a simple fix to the TCP_server code to at least look for a -special packet like this and be nice and send a simple nice reply like -the UDP case. Raised as https://github.com/TokTok/c-toxcore/issues/2331 - -We should not kid ourselves that we don't all live in China or Iran - -the planet is in a loc$down, and I think we might quickly find out just -how much resiliance we need. s/China/Iran/Syria/Russia/GDR - -* https://www.themoscowtimes.com/2021/12/07/why-the-kremlin-blocking-tor-is-a-big-deal-a75751 -* https://www.wired.com/story/russia-block-tor-censorship/ -* https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook -* https://www.lifesitenews.com/news/biden-executive-order-allows-spying-on-americans-to-assess-political-instability-climate-threats/ - -Up: [[DDosSmallNumberOfBSNodes]] +Up: [[Home]] + +From: https://github.com/TokTok/c-toxcore/issues/419 + +I don't think indistinguishable message bytes and sizes are going to +make any difference when they are sent over a network of so few bootstrap nodes. +And anyone operating in a hostile environment is probably already +running Tox over [Tor](https://www.torproject.org/download), which works well. + +Did the reports of blocking in China include blocking over Tor? +Tor itself has implemented pluggable transport mechanisms that are +continuously being improved, and these include ways to make the +traffic look like another protocol like HTTP or whatever: + + +So the best way to handle this may be to improve the documentation in +Tox of how to use Tor, and how to configure Tor to use pluggable transports (obfs4). +Whether or not you trust Tor (you can't trust Exit nodes 40% of the time) +they are the only things that work right now in e.g. Egypt or Iran. + +I also think the only way of getting a lot of resilience "cheaply" is +to encourage bootstrap node operators to also run a Tor client to serve +the BS node over Onionv3. This is the only way I can see dealing with the +fact that Tox is a network of so few bootstrap nodes. If the Tox nodebase was +improved to serve BS nodes, and OnionV3 relays, it would be much more resilient. +I'm assuming the adversaries cannot block .onion addresses within Tor, +which I think is a valid assumption. + +There is a way of configuring a Tor client to uniquely assign a +life-of-the-tor-instance IPv4 address from a predefined private range +(VirtualAddrNetworkIPv4) to each onion address it sees: +```AutomapHostsOnResolve 1```. So Tox could use OnionV3 BS nodes in a +properly configured Tor with just some properly configured BS hosts lists +(if enough BS nodes provided OnionV3 addresses). Then we could leave +the heavy lifting of the +[cat-and-mouse games](https://github.com/guardianproject/orbot/issues/742) +of pluggable transports etc. to Tor, and not try to chase them ourselves. + +If you have such a list of onion addresses, the Tor user, who is running a Tor +instance anyway to connect with the Tox client, adds this to the ```/etc/tor/torrc``` +``` +VirtualAddrNetworkIPv4 172.16.0.0/12 +AutomapHostsOnResolve 1 +``` +Then with the list of onion addresses for BS nodes that are running Tox as OnionV3, +then you can use ```tor-resolve``` or ```tor-resolve -4``` to get the +good-for-you-only IP addresses of OnionV3 BS nodes in IPv4. So the Tox user +does this and puts these addresses into his ```DHTnodes.json``` and boostraps his +Tox client over Tor Onions. This works with libtoxcore is it is today, as long as +your client doesn't suffer from the dreaded deranged-hard-coded-bs syndrome. + +These steps would be automated by a simple bash or Python script, perhaps a +Python script wrapped into an exe for Windows/Android. These addresses are +good for life of the Tor instance, and the script would need rerunning +when Tor is restarted. You can also get the IPv4 address of each Onion BS node, +(for-life-of-the-tor-instance which is usually long enough) in +Python using the Tor stem library. + +The best thing we can do is to make these instructions available with +Tox downloads, and to ensure that all distributions of Tox come with +```tor-resolve``` on all platforms. I doubt it comes with +[Orbot on Android](https://github.com/guardianproject/orbot/releases) +and I doubt it comes with [Tor](https://www.torproject.org/download/) or +[Torbrowser on Windows](https://www.torproject.org/download/). +We could ask the maintainers of +[TRIfA](https://f-droid.org/en/packages/com.zoffcc.applications.trifa/) and +[aTOX](https://f-droid.org/en/packages/ltd.evilcorp.atox) to include +it in their distributions, and it would be simple for us to compile a version +of ```tor-resolve``` for our packages to make sure it is available to our users. +It's a static utility that rarely changes. + +I've tried this but it's currently impossible to test as there is no equivalent +to the ```other/fun/bootstrap_node_info.py``` script for TCP connections. +For UDP you can send a packet of len 78 with the magic first bytes and get a +version and MOTD reply. Not so for TCP (in fact if you do send such a packet +to the TCP it send the BS node into an +[infinite loop for which it neverrecovers](https://github.com/TokTok/c-toxcore/issues/2332)). +So we need a simple fix to the TCP_server code to at least look for a +special packet like this and be nice and send a simple nice reply like +the UDP case. Raised as https://github.com/TokTok/c-toxcore/issues/2331 + +We should not kid ourselves that we don't all live in China or Iran - +the planet is in a loc$down, and I think we might quickly find out just +how much resiliance we need. s/China/Iran/Syria/Russia/GDR + +* https://www.themoscowtimes.com/2021/12/07/why-the-kremlin-blocking-tor-is-a-big-deal-a75751 +* https://www.wired.com/story/russia-block-tor-censorship/ +* https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook +* https://www.lifesitenews.com/news/biden-executive-order-allows-spying-on-americans-to-assess-political-instability-climate-threats/ + +Up: [[DDosSmallNumberOfBSNodes]] + diff --git a/ToxComparedWithOtherIm.md b/ToxComparedWithOtherIm.md index bc27dea..1df1f11 100644 --- a/ToxComparedWithOtherIm.md +++ b/ToxComparedWithOtherIm.md @@ -1,68 +1,68 @@ -Up: [[SecurityVulnerabilities]] - -# Tox Compared With Other IM software - -## DeCentralized - -### richochet - -Always uses Tor, rather than Tox, where Tor can be used at will. - -* https: certificate expired over a year ago, and latest version in 2016. -* last updated 2017. - -Relaunched as - -* no group chat -* can't use system Tor - only its own -* didn't see any mobile apps -* Had a [vulnerability](https://thehackernews.com/2016/02/ricochet-secure-messenger.html) with [HTML in invites](https://ricochet.im/files/ricochet-ncc-audit-2016-01.pdf) - -### briar - -* https://briarproject.org/ -* https://code.briarproject.org/briar/briar-desktop/ - -Features: - -* Peer-to-peer encrypted messaging and forums -* Messages are stored securely on your device, not in the cloud -* Connect directly with nearby contacts - no Internet access required -* written in Java -* Uses Tor. -* has an [Android](https://briarproject.org/installing-briar-via-f-droid/) app and desktop (the app is more featured than the desktop) -* No support for Windows and macOS -* chats and groupchats -* [Well documented](https://code.briarproject.org/briar/briar/-/wikis/home) -* [Externally Audited](https://briarproject.org/raw/BRP-01-report.pdf): "the quality and readability of the app’s source code was rather exceptional" -* USGov funded: Open Technology Fund/U.S. Agency for Global Media/Radio Free Asia -* The apps are betas that expire in 90 days: "For security reasons, their accounts and data will expire with the beta." - -### ZeroNet - -* Abandonned by its creator, it is being carried on by a number of - non-cooperating forks. -* A known RCE vulnerability is in some of the forks, but the developers - of the patched forks have not filed a CVE. -* None of the current developers have write access to the main web site, - which distributes code with the CVE. - - -## Centralized - -Centralized systems make it easy to MITM the E2E crypto, so unless they -are open source, they can't be trustworthy. - -It is *much* harder to Tox over Tor than to block services like -WhatsApp which relay on centralized servers. - -### WhatsApp - -* https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security - -## Signal - -[Signal](https://dt.gl/the-2021-review-of-messaging-service-providers-movim/) -not only uses Amazon Web Services servers but also Microsoft and Google servers, -and now to make things even more toxic they are also using +Up: [[SecurityVulnerabilities]] + +# Tox Compared With Other IM software + +## DeCentralized + +### richochet + +Always uses Tor, rather than Tox, where Tor can be used at will. + +* https: certificate expired over a year ago, and latest version in 2016. +* last updated 2017. + +Relaunched as + +* no group chat +* can't use system Tor - only its own +* didn't see any mobile apps +* Had a [vulnerability](https://thehackernews.com/2016/02/ricochet-secure-messenger.html) with [HTML in invites](https://ricochet.im/files/ricochet-ncc-audit-2016-01.pdf) + +### briar + +* https://briarproject.org/ +* https://code.briarproject.org/briar/briar-desktop/ + +Features: + +* Peer-to-peer encrypted messaging and forums +* Messages are stored securely on your device, not in the cloud +* Connect directly with nearby contacts - no Internet access required +* written in Java +* Uses Tor. +* has an [Android](https://briarproject.org/installing-briar-via-f-droid/) app and desktop (the app is more featured than the desktop) +* No support for Windows and macOS +* chats and groupchats +* [Well documented](https://code.briarproject.org/briar/briar/-/wikis/home) +* [Externally Audited](https://briarproject.org/raw/BRP-01-report.pdf): "the quality and readability of the app’s source code was rather exceptional" +* USGov funded: Open Technology Fund/U.S. Agency for Global Media/Radio Free Asia +* The apps are betas that expire in 90 days: "For security reasons, their accounts and data will expire with the beta." + +### ZeroNet + +* Abandonned by its creator, it is being carried on by a number of + non-cooperating forks. +* A known RCE vulnerability is in some of the forks, but the developers + of the patched forks have not filed a CVE. +* None of the current developers have write access to the main web site, + which distributes code with the CVE. + + +## Centralized + +Centralized systems make it easy to MITM the E2E crypto, so unless they +are open source, they can't be trustworthy. + +It is *much* harder to Tox over Tor than to block services like +WhatsApp which relay on centralized servers. + +### WhatsApp + +* https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security + +## Signal + +[Signal](https://dt.gl/the-2021-review-of-messaging-service-providers-movim/) +not only uses Amazon Web Services servers but also Microsoft and Google servers, +and now to make things even more toxic they are also using [Cloudflare](https://dt.gl/cloudflare-why-the-fuss/) which makes in unusable with Tor. \ No newline at end of file diff --git a/ToxMultiDevice.md b/ToxMultiDevice.md index d2aa266..4466302 100644 --- a/ToxMultiDevice.md +++ b/ToxMultiDevice.md @@ -1,318 +1,318 @@ -# Toxcore Multi-Device Support Design Proposal - - - -To be a useable communication system, Tox needs to support multiple -devices per user. This is the [TokTok](https://toktok.ltd) proposal. - -## Objective - -This proposal is an RFC for a possible implementation of multi-device -support for the Toxcore Messenger system. With the goal of replacing -Skype we must come close to feature parity, as well as ease of -use. Currently Tox clients need to share a ToxID. This ID inhibits -connecting with existing friends as it is only well-suited to machine -reading. - - -The primary goal is to make it simple for clients to securely implement multi-device support, without having to know or manage anything about a contact’s devices. - - -The following implementation requires some additional features to be -added to Toxcore. These features have been requested before; however, -the goal of this implementation is to add Multi-Device support -only. The additional APIs that would be required (see next section) -would only need to be minimal implementations to get multi-device -working. And while their feature set should be expanded, that’s not -the goal of this implementation. - -## Background - -ToxID’s are difficult to share without having an existing textual -communication connection (anything you can copy from or paste -to). Sharing ToxID’s in other ways is problematic. - -When it comes to multi-device support, at the present time we are -lagging behind well-known centralized messenger systems. A few -examples are Google Hangouts, Facebook Messenger, and Skype. Every one -of these syncs messages to every device which connects to their -network. If you need an address, number, or entire friend list it’s a -simple login away. - -Not the goal of this project but an important benefit, Multi-Device -support would solve some of the issues sharing a ToxID: it would allow -the clients to connect with mobile devices (NFC, QR codes, other) and -be available anywhere. - -## Prerequisites - -### Data Syncing (Friends and Messages): - -Devices may go online and offline. It’s required that an online device be able to keep other devices in the “device group” in sync, Updating both friends and messages.(a)[^1](b)[^2] - -### Contact Syncing - -Contacts (called friends in the Toxcore API) are synced across all -devices using a transactional method. As a pair the devices decide -which will have the primary role, and which will take secondary. -hroughout the entire syncing process, the primary device will send -it’s data, followed by a “done” packet. The secondary will then send -its data, followed by its own “done” packet. The primary device will -then send a “commit” packet, and will then commit the data from -temporary storage, into active use. Once receiving the “commit” -packet, the secondary device will do the same. - -Either Client can send an Error packet at either time, which will then -Message ordering - -Devices may sync out of order, but messages need to be consistently -ordered. To simplify this, messages will be separated into “connection -sessions”, each getting a pseudorandom tox_session_ID. Messages will -then be ordered within that session by a delta_t. Delta_t in this case -will be the elapsed seconds from the start of the tox instance’s first -current connection to that peer. - - -Each session will be identified by a pseudo-unique hash from the -previous connect that included a confirmed message receipt. This will -ensure that both sessions and messages are ordered correctly once each -client is completely synced. (Optionally robust verifiability can be -gained by a git style hash of the x parent sessions) - -### Pseudo-unique Message IDs - -#### Update - -``` -typedef void tox_friend_message_cb(Tox *tox, uint32_t friend_number, TOX_MESSAGE_TYPE type, const uint8_t *message, size_t length, void *user_data); -``` -with -``` -typedef void tox_friend_message_cb(Tox *tox, uint32_t friend_number, TOX_MESSAGE_TYPE type, const uint8_t *message, size_t length, uint64_t message_id, uint64_t delta_t, void *user_data); -``` - -Required for syncing messages between friends * devices. Each message -would include a message_id that would increment with each message. and -reset with each new tox_instance (starting message ID is currently -undecided). Messages id sections would have to be grouped by a client -coming online or going offline. These are per friend, per -connection. And would be the same when sending the same message to -multiple devices of a single friend. - - -Each of these are pending an implementation spec. But are self-evident -in their use and general implementation. - -## Implementation - -Security and safety is the primary concern, however this needs to be tempered with usability. The user needs to be prompted to choose high availability or high security. - -### Device IDs - -Device IDs need to be unique and never changing. On each connect, each -client should query each friend they connect to, to verify if they -support multi-device AND are in a group. This can be done by asking -for the deviceID at ```__device0```. If there is a device at that -address; then enumerate for each other device. Devices will be found -by the string_to_id service using the protected `__device[0-9]+` -group. (Toxcore must protect strings that start with two underscores -such as “__[string]”, and not allow a client to use them in the -string_to_id API.) - - -Starting with ```__device0```, the client will attempt to resolve the -ToxID at each incrementing ```__device#```. Once a ```__device#``` -returns empty, the client should stop. Each ```__device#``` string -should be queried separately, ideally in a pseudo-random order to -prevent clear text attacks on the encryption. {under discussion} For -each ToxID at each ```__device#``` the client must add them to their -list of devices for this friend/user, and probe each device in the -same way. The default should be high security mode, in which if any -list at any device do not match, toxcore should report that friend to -be in an unsecure state, and shouldn’t send any messages to any of the -devices. - - -The ```__device#``` list for every client must match exactly to what every other device reports. And each ```__device#``` once used must always resolve to that ID. - - -To enhance security once a ```__device#``` (number) is taken by a -device, that ```__device#``` must always resolve to either the same -ToxID, or to all zeroes [0] if the device has been removed from the -Tox “group” by the user, in a case such as losing the private key, or -uninstalling the Tox client. Toxcore will maintain a local list of -each device for each user, changes to a ```__device#``` will be -assumed to be an impersonation attack. Removed devices will still keep -their ```__device#```, but that ```__device#``` will instead resolve -to zeros. A string of zeros signifies that there was a device, but it -was removed intentionally. A ```__device#``` once resolved to zeros, -must never change back to a ToxID. - - -To remove or add a device, you will tell toxcore to add the device at -ToxID to this group. That toxcore instance will then, try to connect -to that device and verify that it also wants to connect to the -existing device group. Once accepted, the toxcore instance on the -primary device will assign a ```__device#``` to the new device, and -sync both it’s ID, to the other devices already in the group, as well -as the existing devices to the new device. Once all the devices in the -group are in sync, any of the existing and online devices can sync the -friend/contact list, and the selected amount of history text history -to the new device. - - -A max limit of devices will need to be chosen later to limit worst -case usage of enumerating devices. (Additional protocol requirements -will be detailed later, i.a. security limitations, verifiable, master -device, slave device, deauthed devices.) - -## Message sending - -When a client sends a message to a friend/user, Toxcore will only -attempt to send the message to the last 3 devices that sent data from -the user that are online.(c)[^3] (d)[^4] (e)[^5] E.g., Device_A sends a -message, Device_B comes online, Device_C sends a file, Device_D sends -a message then goes off line, Device_F sends a picture, Device_H comes -online. Toxcore will attempt to send only to devices A, C and F. While -H did have the latest data sent/received, it wasn’t data generated by -the user, so we assume that the user is most likely to be on one of -those 3 devices. Toxcore will only have to verify that one client -received the message, and may stop. This will protect the sender from -having to maintain a list of who needs what message, and leave the -additional data syncing up to the receiving client. - -It is considered the job of the receiving client to keep all the other -devices in sync with the rest of the group. - -### Alternatives Considered - -1. Not supporting multi-device (separate friends in the contact list for each device). - * Not considered, this feature is required to be competitive. Not user friendly, no syncing, too hard to create and maintain friend lists. - -2. Sharing the private key of a single ToxID to multiple devices. - * Non starter. Security nightmare. - * Requires protocol rewrite. - -3. [[GroupOfDevicesPOC]] - -4. [[MultiDeviceAnnouncementsPOC]] - -### Unsolved Issues - -How will messages be hashed to generate the seed for the message ID? - - -Effective and secure history syncing across devices. - - -How to add a user to your contact list -* By Primary ToxID(f)[^6](g)[^7] -* By any deviceID -* Something else? - -## Roadmap - -1. Unique message IDs - 1. incrementing numbers - 2. delta-from last -2. Device network - 1. deviceID vs toxID - 2. Adding a device - 3. Removing a device - 4. Sending a message to more than one device -3. Syncing data - 1. contact list - 2. messages - 3. other? - -## Notes & FAQ: - -Conversations that need to be added to the spec: -``` - say Alice has a tox client running on a phone and another tox client on pc. Alice has Bob in contacts. Bob is online and sends Alice a file. - will Alice see the file request on both clients? - the file request will go to all online devices - ok, i'm not finished - then the file will get canceled / "marked as accpeted on a different device" - so, Alice accepts and completes the file transfer on her phone -``` -(h)[^8] (i)[^9] (j)[^10] -``` - i guess you answered what i wanted to know - what if race condition happens? - but I hadn't considered that detail... It'll break the existing file transfer API... - Alice accepts files at the same time both on pc and phone? - nurupo, can't happen - why it can't happen? - the accept will processed by toxcore on the "sending" device in a single thread, it'll accept for the first device that accepts the transfer, then cancel all other divices - if two devices accept at the same time, toxcore will choose the device in the lowest number slot only because the loop will start at 0 - what if Alice accepts a file on another device before it gets the cancel message? - it'll show inprogress on that device, with 0 transfer, then toxcore on the sending device will still send the cancel to that device - Bob will get two accepts from two devices of Alice? - yes, but it will ignore the 2nd - how it knows which to ignore? - (I'm saying all of this from what my plans are, I haven't even started on filetransfers yet) - psudo code -> - Alice might have accepted the file transfer on the phone first, but because of network latency, Bob received the acceptance from pc first and only then from the phone - OH - bob will in that case cancel the phone then -``` -(k)[^11] -``` - fair enough - no reason to make it more complicated then it needs to be -``` - - -### Feature Requests: - -(Requested publicly, no suggestions have been reviewed or accepted yet.) - -* Per device id priority like with XMPP https://wiki.xmpp.org/web/Jabber_Resources - * Per status+deviceid priority, XMPP does that as well - -* Ability to address device id explicitly - -## Footnotes - -* (a)[^1] Does this design document define a way in which friends (and perhaps groups) are to be synced? And how would friend/group syncing work across multi-devices that don't have a common time base? - -* (b)[^2] I haven't fully decided on the final spec for this question. - - -Currently my plan is to retain information about changes as a numerical delta, and use the largest delta. But as I haven't started on this section, really I have no idea. - -* (c)[^3] What about in the case of an A/V call? Does that get broadcast to call connected clients or only the last 3? A tox client running on a mobile device that had not sent a user-generated message missing a call would be bad. - -* (d)[^4] I'm likely to drop that idea in total. - -Currently toxcore sends everything to all devices. -* (e)[^5] With other services such as Discord, when a call comes in depending on what is on, I could have two PCs, a laptop and cellphone all ring, but whatever device I answer on obviously gets the call. - -* (f)[^6] how is primary toxID different from any other ID? which device is the primary one? as far as I understood they are all equal. - -* (g)[^7] I'm not sure there's going to be anything like a primary ID in the final source. When discussing it, the idea of a master device came up as a security tool. But the longer I consider it, the less I think it'll help at all - -* (h)[^8] Does it make sense to think about sending the file to both - clients, if the user accepts on multiple devices? Especially for - bigger files or multiple recipients a P2P protocol (e.g. torrent) - may be useful. - -* (i)[^9] Yeah, I've given that a little thought. The current idea - floating around has been to implement something torrent like inside - group chats. Maybe we could use that as well? As far as multiple - devices, what I think is best is transfer the file to the first to - accept, then let the other devices sync the file themselves. That - way the sender doesn't have to spend the extra data for the - receivers convenience. - -* (j)[^10] I like that idea. Especially if one thinks about those users - on a phone with limited traffic. You wouldn't want to use all your - available data just so others can sync. You could add a button on - top of lets say a picture saying "sync with my other devices" to - start the transfer of that picture to all your other devices. But - just sending it once should be a lot easier. I'd consider media sync - between my devices as a nice-to-have. - -* (k)[^11] Could it be a good idea to allow sync incomplete downloaded - files from device A to device B and then start downloading from device B +# Toxcore Multi-Device Support Design Proposal + + + +To be a useable communication system, Tox needs to support multiple +devices per user. This is the [TokTok](https://toktok.ltd) proposal. + +## Objective + +This proposal is an RFC for a possible implementation of multi-device +support for the Toxcore Messenger system. With the goal of replacing +Skype we must come close to feature parity, as well as ease of +use. Currently Tox clients need to share a ToxID. This ID inhibits +connecting with existing friends as it is only well-suited to machine +reading. + + +The primary goal is to make it simple for clients to securely implement multi-device support, without having to know or manage anything about a contact’s devices. + + +The following implementation requires some additional features to be +added to Toxcore. These features have been requested before; however, +the goal of this implementation is to add Multi-Device support +only. The additional APIs that would be required (see next section) +would only need to be minimal implementations to get multi-device +working. And while their feature set should be expanded, that’s not +the goal of this implementation. + +## Background + +ToxID’s are difficult to share without having an existing textual +communication connection (anything you can copy from or paste +to). Sharing ToxID’s in other ways is problematic. + +When it comes to multi-device support, at the present time we are +lagging behind well-known centralized messenger systems. A few +examples are Google Hangouts, Facebook Messenger, and Skype. Every one +of these syncs messages to every device which connects to their +network. If you need an address, number, or entire friend list it’s a +simple login away. + +Not the goal of this project but an important benefit, Multi-Device +support would solve some of the issues sharing a ToxID: it would allow +the clients to connect with mobile devices (NFC, QR codes, other) and +be available anywhere. + +## Prerequisites + +### Data Syncing (Friends and Messages): + +Devices may go online and offline. It’s required that an online device be able to keep other devices in the “device group” in sync, Updating both friends and messages.(a)[^1](b)[^2] + +### Contact Syncing + +Contacts (called friends in the Toxcore API) are synced across all +devices using a transactional method. As a pair the devices decide +which will have the primary role, and which will take secondary. +hroughout the entire syncing process, the primary device will send +it’s data, followed by a “done” packet. The secondary will then send +its data, followed by its own “done” packet. The primary device will +then send a “commit” packet, and will then commit the data from +temporary storage, into active use. Once receiving the “commit” +packet, the secondary device will do the same. + +Either Client can send an Error packet at either time, which will then +Message ordering + +Devices may sync out of order, but messages need to be consistently +ordered. To simplify this, messages will be separated into “connection +sessions”, each getting a pseudorandom tox_session_ID. Messages will +then be ordered within that session by a delta_t. Delta_t in this case +will be the elapsed seconds from the start of the tox instance’s first +current connection to that peer. + + +Each session will be identified by a pseudo-unique hash from the +previous connect that included a confirmed message receipt. This will +ensure that both sessions and messages are ordered correctly once each +client is completely synced. (Optionally robust verifiability can be +gained by a git style hash of the x parent sessions) + +### Pseudo-unique Message IDs + +#### Update + +``` +typedef void tox_friend_message_cb(Tox *tox, uint32_t friend_number, TOX_MESSAGE_TYPE type, const uint8_t *message, size_t length, void *user_data); +``` +with +``` +typedef void tox_friend_message_cb(Tox *tox, uint32_t friend_number, TOX_MESSAGE_TYPE type, const uint8_t *message, size_t length, uint64_t message_id, uint64_t delta_t, void *user_data); +``` + +Required for syncing messages between friends * devices. Each message +would include a message_id that would increment with each message. and +reset with each new tox_instance (starting message ID is currently +undecided). Messages id sections would have to be grouped by a client +coming online or going offline. These are per friend, per +connection. And would be the same when sending the same message to +multiple devices of a single friend. + + +Each of these are pending an implementation spec. But are self-evident +in their use and general implementation. + +## Implementation + +Security and safety is the primary concern, however this needs to be tempered with usability. The user needs to be prompted to choose high availability or high security. + +### Device IDs + +Device IDs need to be unique and never changing. On each connect, each +client should query each friend they connect to, to verify if they +support multi-device AND are in a group. This can be done by asking +for the deviceID at ```__device0```. If there is a device at that +address; then enumerate for each other device. Devices will be found +by the string_to_id service using the protected `__device[0-9]+` +group. (Toxcore must protect strings that start with two underscores +such as “__[string]”, and not allow a client to use them in the +string_to_id API.) + + +Starting with ```__device0```, the client will attempt to resolve the +ToxID at each incrementing ```__device#```. Once a ```__device#``` +returns empty, the client should stop. Each ```__device#``` string +should be queried separately, ideally in a pseudo-random order to +prevent clear text attacks on the encryption. {under discussion} For +each ToxID at each ```__device#``` the client must add them to their +list of devices for this friend/user, and probe each device in the +same way. The default should be high security mode, in which if any +list at any device do not match, toxcore should report that friend to +be in an unsecure state, and shouldn’t send any messages to any of the +devices. + + +The ```__device#``` list for every client must match exactly to what every other device reports. And each ```__device#``` once used must always resolve to that ID. + + +To enhance security once a ```__device#``` (number) is taken by a +device, that ```__device#``` must always resolve to either the same +ToxID, or to all zeroes [0] if the device has been removed from the +Tox “group” by the user, in a case such as losing the private key, or +uninstalling the Tox client. Toxcore will maintain a local list of +each device for each user, changes to a ```__device#``` will be +assumed to be an impersonation attack. Removed devices will still keep +their ```__device#```, but that ```__device#``` will instead resolve +to zeros. A string of zeros signifies that there was a device, but it +was removed intentionally. A ```__device#``` once resolved to zeros, +must never change back to a ToxID. + + +To remove or add a device, you will tell toxcore to add the device at +ToxID to this group. That toxcore instance will then, try to connect +to that device and verify that it also wants to connect to the +existing device group. Once accepted, the toxcore instance on the +primary device will assign a ```__device#``` to the new device, and +sync both it’s ID, to the other devices already in the group, as well +as the existing devices to the new device. Once all the devices in the +group are in sync, any of the existing and online devices can sync the +friend/contact list, and the selected amount of history text history +to the new device. + + +A max limit of devices will need to be chosen later to limit worst +case usage of enumerating devices. (Additional protocol requirements +will be detailed later, i.a. security limitations, verifiable, master +device, slave device, deauthed devices.) + +## Message sending + +When a client sends a message to a friend/user, Toxcore will only +attempt to send the message to the last 3 devices that sent data from +the user that are online.(c)[^3] (d)[^4] (e)[^5] E.g., Device_A sends a +message, Device_B comes online, Device_C sends a file, Device_D sends +a message then goes off line, Device_F sends a picture, Device_H comes +online. Toxcore will attempt to send only to devices A, C and F. While +H did have the latest data sent/received, it wasn’t data generated by +the user, so we assume that the user is most likely to be on one of +those 3 devices. Toxcore will only have to verify that one client +received the message, and may stop. This will protect the sender from +having to maintain a list of who needs what message, and leave the +additional data syncing up to the receiving client. + +It is considered the job of the receiving client to keep all the other +devices in sync with the rest of the group. + +### Alternatives Considered + +1. Not supporting multi-device (separate friends in the contact list for each device). + * Not considered, this feature is required to be competitive. Not user friendly, no syncing, too hard to create and maintain friend lists. + +2. Sharing the private key of a single ToxID to multiple devices. + * Non starter. Security nightmare. + * Requires protocol rewrite. + +3. [[GroupOfDevicesPOC]] + +4. [[MultiDeviceAnnouncementsPOC]] + +### Unsolved Issues + +How will messages be hashed to generate the seed for the message ID? + + +Effective and secure history syncing across devices. + + +How to add a user to your contact list +* By Primary ToxID(f)[^6](g)[^7] +* By any deviceID +* Something else? + +## Roadmap + +1. Unique message IDs + 1. incrementing numbers + 2. delta-from last +2. Device network + 1. deviceID vs toxID + 2. Adding a device + 3. Removing a device + 4. Sending a message to more than one device +3. Syncing data + 1. contact list + 2. messages + 3. other? + +## Notes & FAQ: + +Conversations that need to be added to the spec: +``` + say Alice has a tox client running on a phone and another tox client on pc. Alice has Bob in contacts. Bob is online and sends Alice a file. + will Alice see the file request on both clients? + the file request will go to all online devices + ok, i'm not finished + then the file will get canceled / "marked as accpeted on a different device" + so, Alice accepts and completes the file transfer on her phone +``` +(h)[^8] (i)[^9] (j)[^10] +``` + i guess you answered what i wanted to know + what if race condition happens? + but I hadn't considered that detail... It'll break the existing file transfer API... + Alice accepts files at the same time both on pc and phone? + nurupo, can't happen + why it can't happen? + the accept will processed by toxcore on the "sending" device in a single thread, it'll accept for the first device that accepts the transfer, then cancel all other divices + if two devices accept at the same time, toxcore will choose the device in the lowest number slot only because the loop will start at 0 + what if Alice accepts a file on another device before it gets the cancel message? + it'll show inprogress on that device, with 0 transfer, then toxcore on the sending device will still send the cancel to that device + Bob will get two accepts from two devices of Alice? + yes, but it will ignore the 2nd + how it knows which to ignore? + (I'm saying all of this from what my plans are, I haven't even started on filetransfers yet) + psudo code -> + Alice might have accepted the file transfer on the phone first, but because of network latency, Bob received the acceptance from pc first and only then from the phone + OH + bob will in that case cancel the phone then +``` +(k)[^11] +``` + fair enough + no reason to make it more complicated then it needs to be +``` + + +### Feature Requests: + +(Requested publicly, no suggestions have been reviewed or accepted yet.) + +* Per device id priority like with XMPP https://wiki.xmpp.org/web/Jabber_Resources + * Per status+deviceid priority, XMPP does that as well + +* Ability to address device id explicitly + +## Footnotes + +* (a)[^1] Does this design document define a way in which friends (and perhaps groups) are to be synced? And how would friend/group syncing work across multi-devices that don't have a common time base? + +* (b)[^2] I haven't fully decided on the final spec for this question. + + +Currently my plan is to retain information about changes as a numerical delta, and use the largest delta. But as I haven't started on this section, really I have no idea. + +* (c)[^3] What about in the case of an A/V call? Does that get broadcast to call connected clients or only the last 3? A tox client running on a mobile device that had not sent a user-generated message missing a call would be bad. + +* (d)[^4] I'm likely to drop that idea in total. + +Currently toxcore sends everything to all devices. +* (e)[^5] With other services such as Discord, when a call comes in depending on what is on, I could have two PCs, a laptop and cellphone all ring, but whatever device I answer on obviously gets the call. + +* (f)[^6] how is primary toxID different from any other ID? which device is the primary one? as far as I understood they are all equal. + +* (g)[^7] I'm not sure there's going to be anything like a primary ID in the final source. When discussing it, the idea of a master device came up as a security tool. But the longer I consider it, the less I think it'll help at all + +* (h)[^8] Does it make sense to think about sending the file to both + clients, if the user accepts on multiple devices? Especially for + bigger files or multiple recipients a P2P protocol (e.g. torrent) + may be useful. + +* (i)[^9] Yeah, I've given that a little thought. The current idea + floating around has been to implement something torrent like inside + group chats. Maybe we could use that as well? As far as multiple + devices, what I think is best is transfer the file to the first to + accept, then let the other devices sync the file themselves. That + way the sender doesn't have to spend the extra data for the + receivers convenience. + +* (j)[^10] I like that idea. Especially if one thinks about those users + on a phone with limited traffic. You wouldn't want to use all your + available data just so others can sync. You could add a button on + top of lets say a picture saying "sync with my other devices" to + start the transfer of that picture to all your other devices. But + just sending it once should be a lot easier. I'd consider media sync + between my devices as a nice-to-have. + +* (k)[^11] Could it be a good idea to allow sync incomplete downloaded + files from device A to device B and then start downloading from device B diff --git a/ToxNetworkResilience.md b/ToxNetworkResilience.md index c469ab9..022399b 100644 --- a/ToxNetworkResilience.md +++ b/ToxNetworkResilience.md @@ -32,7 +32,7 @@ configuration: # Tox hidden service configuration. HiddenServiceDir /var/lib/tor/tox-hsv3/ HiddenServicePort 3389 127.0.0.1:3389 -HiddenServicePort 3389 127.0.0.1:33446 +HiddenServicePort 33446 127.0.0.1:33446 ``` assuming your Tor lib directory os ```/var/lib/tor```. In that subdirectory you will find a file named ```hostname``` which is the ```.onion``` name diff --git a/UseGroupPasswordThroughAKDF.md b/UseGroupPasswordThroughAKDF.md index 8bbff3f..6e184fb 100644 --- a/UseGroupPasswordThroughAKDF.md +++ b/UseGroupPasswordThroughAKDF.md @@ -1,6 +1,6 @@ -Up: [[SecurityVulnerabilities]] - -Chatting with sudden6 (Sep 2022) says this still an open vulnerability. - -Use the group password only through a KDF by sudden6 - +Up: [[SecurityVulnerabilities]] + +Chatting with sudden6 (Sep 2022) says this still an open vulnerability. + +Use the group password only through a KDF by sudden6 + diff --git a/VulnerabilitiesInTheToxOnion.md b/VulnerabilitiesInTheToxOnion.md index 39b4fae..4721598 100644 --- a/VulnerabilitiesInTheToxOnion.md +++ b/VulnerabilitiesInTheToxOnion.md @@ -1,9 +1,9 @@ -Up: [[SecurityVulnerabilities]] - -Chatting with JF (Aug 2022) makes me think that these are still open: -Known vulnerabilities in the tox onion: - -* -* - -[algor1th](https://github.com/algor1th) created a formal model that shows that announcements are linkable, and note trace equivalent to searches. It can be found at https://github.com/algor1th/tox-verification/blob/master/dht.dps. Linkability here means that a public key of a node can be linked to it's ip adress when announcing. +Up: [[SecurityVulnerabilities]] + +Chatting with JF (Aug 2022) makes me think that these are still open: +Known vulnerabilities in the tox onion: + +* +* + +[algor1th](https://github.com/algor1th) created a formal model that shows that announcements are linkable, and note trace equivalent to searches. It can be found at https://github.com/algor1th/tox-verification/blob/master/dht.dps. Linkability here means that a public key of a node can be linked to it's ip adress when announcing. diff --git a/_Footer.md b/_Footer.md index f834bf8..c0e901a 100644 --- a/_Footer.md +++ b/_Footer.md @@ -1 +1 @@ -Up: [[Home]] +Up: [[Home]]