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

Tox over Tor

emdee 2022-10-15 10:21:23 +00:00
parent 1b956831db
commit 146a54ff7e
13 changed files with 1003 additions and 988 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

118
DDosSmallNumberOfBSNodes.md

@ -1,59 +1,59 @@
Previous: [[SecurityVulnerabilities]] Previous: [[SecurityVulnerabilities]]
By design, Tox relies on a small number of BS nodes. As the network 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 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 is vulnerable to being completely taken down by blocking a small
number of nodes. number of nodes.
The same problem, to a lesser extent affects Tor, although they have a 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 few thousand nodes. Doing the best we can with what we have, we can
take advantage of something from libtoxcore: the ```tcp_server slot```. take advantage of something from libtoxcore: the ```tcp_server slot```.
It is supported by most clients like toxic or toxygen. It is supported by most clients like toxic or toxygen.
So this is what is proposed: So this is what is proposed:
1. Fix libtoxcore to be able to accept .onion addresses for BS nodes, 1. Fix libtoxcore to be able to accept .onion addresses for BS nodes,
or test the workarounds: see [[ToxAndTorInChinaAndIran]]. or test the workarounds: see [[ToxAndTorInChinaAndIran]].
2. All BS node operators are asked to also run a Tor client (not exit node), 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 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 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. 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. 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. 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. 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 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 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, (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 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. 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 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. (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. 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. 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 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```. or splash screen ask them to run a ```tcp_server```.
5. Improve the client documentation on how to run Tox over Tor, 5. Improve the client documentation on how to run Tox over Tor,
particularly for Android users: how to download Orbot from particularly for Android users: how to download Orbot from
<https://f-droid.org> (preferred over Srewgle Play) and configure them. <https://f-droid.org> (preferred over Srewgle Play) and configure them.
Tell them to try first running Orbot and a browser that works with it, 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 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. 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, 6. Improve our ability to monitor network performance, including TCP relays,
so we can detect if anyone is attacking the network. 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 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 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. 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 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 there is good availability and redundancy, and fix the minor problems
needed for Tox to work with onion BS nodes. needed for Tox to work with onion BS nodes.

24
GroupOfDevicesPOC.md

@ -1,12 +1,12 @@
Previous: [[Home]] Previous: [[Home]]
## Group Of Devices POC ## 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. 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; It may not scale well because messaging is sent to all devices of all users;
a single active user approach would be more efficient. a single active user approach would be more efficient.
And it wouldn't work for groups very well as a group-of-devices can And it wouldn't work for groups very well as a group-of-devices can
not be a member of an NGC group. not be a member of an NGC group.

64
Home.md

@ -1,32 +1,32 @@
# Welcome to the Wiki. # Welcome to the Wiki.
What I am noticing is that there is no notion of a Tox Improvement What I am noticing is that there is no notion of a Tox Improvement
Proposal(TIP), so ideas and vulnerabilities get forgotten in Proposal(TIP), so ideas and vulnerabilities get forgotten in
abandonned PRs in abandoned repos, or ignored issues. abandonned PRs in abandoned repos, or ignored issues.
I suggested wiki.tox.chat as a place to identify and prioritize TIPs 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 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 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 version. developers who know the key exchange mechanisms can bring a
lot of the existing codebase to bear on this problem, and resolve lot of the existing codebase to bear on this problem, and resolve
wrinkles in the concepts. wrinkles in the concepts.
### Multi-Device DHT announcements: ### Multi-Device DHT announcements:
* [[MultiDevice Announcements POC]] * [[MultiDevice Announcements POC]]
* [[GroupOfDevicesPOC]] * [[GroupOfDevicesPOC]]
* Original TokTok ToxMultiDevice: [[ToxMultiDevice]] * Original TokTok ToxMultiDevice: [[ToxMultiDevice]]
### Network Resilience ### Network Resilience
* [[ToxNetworkResilience]] * [[ToxNetworkResilience]]
### Security ### Security
* [[SecurityVulnerabilities]]: * [[SecurityVulnerabilities]]:
** [[UseGroupPasswordThroughAKDF]] ** [[UseGroupPasswordThroughAKDF]]
** [[VulnerabilitiesInTheToxOnion]] ** [[VulnerabilitiesInTheToxOnion]]
** [[DDosSmallNumberOfBSNodes]] ** [[DDosSmallNumberOfBSNodes]]

686
MultiDeviceAnnouncementsPOC.md

@ -1,343 +1,343 @@
Previous: [[Home]] Previous: [[Home]]
## We need to solve the usage of Tox with multiple devices. ## We need to solve the usage of Tox with multiple devices.
This proof-of-concept (POC) is based on the premise that solving the 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 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. with mobiles runs into it, and all the competition software deals with it.
MultiDevice is much easier in centralized systems and our decentalization 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! 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 **Woke Warning:** gender specific, non-android/furry friendly grammar
is used throughout. is used throughout.
The idea here is to address one simple usecase: a person can have 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. 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 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. using so that others can communicate to the device he is currently using.
The POC ignores the problem of history sync that this creates. The POC ignores the problem of history sync that this creates.
Others can address that later perhaps with tools like rsync. Others can address that later perhaps with tools like rsync.
## Background ## Background
When it comes to multi-device support, at the present time we are When it comes to multi-device support, at the present time we are
lagging behind well-known centralized messenger systems. A few lagging behind well-known centralized messenger systems. A few
examples are Google Hangouts, Facebook Messenger, and Skype. Every one examples are Google Hangouts, Facebook Messenger, and Skype. Every one
of these syncs messages to every device which connects to their 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 network. If you need an address, number, or entire friend list it’s a
simple login away. [[ToxMultiDevice]] simple login away. [[ToxMultiDevice]]
Not the goal of this project but an important benefit, Multi-Device 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 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 the clients to connect with mobile devices (NFC, QR codes, other) and
be available anywhere. be available anywhere.
## First Steps ## First Steps
The idea is to firstly define a PersonaID, much like a ToxPk that 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. 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 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 work with PersonaIDs as well as ToxPks. The PersonaIDs would be client
facing, and the ToxPk code would be for internal access. A simple facing, and the ToxPk code would be for internal access. A simple
implementation would be duplicating all code calls that deals with implementation would be duplicating all code calls that deals with
ToxPks to have a layer of calls on top that take the PersonaID and 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 consult a table that contains the active ToxPk, and then calls the
ToxPk function. ToxPk function.
For the sake of argument, let's say that the table is initially For the sake of argument, let's say that the table is initially
populated with all the existing ToxPks by deriving a default PersonaID populated with all the existing ToxPks by deriving a default PersonaID
ToxID by a simple method: the default table contains a PersonaID that ToxID by a simple method: the default table contains a PersonaID that
is the ToxPk (identity table). is the ToxPk (identity table).
So we can add this layer of PersonaID->ToxPk mapping to the library 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 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, 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 -> 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 ToxPks (but maybe not change the entries), and the active ToxPk for
each PersonaID. each PersonaID.
More concretely, the PersonaID mapping table would be like a dictionary 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, with 2 (or more) types of entries; before the arrival of a blob update,
the table is by default (assuming JSON) the table is by default (assuming JSON)
``` ```
{"Pk1": "Pk1", {"Pk1": "Pk1",
"Pk2": "Pk2", "Pk2": "Pk2",
...} ...}
``` ```
So we could get the whole network switched over to accommodating PersonaIDs 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, 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: the PersonaID is an ordered dictionary mapping to a list of device PKs:
``` ```
{"Pk1": "Pe1", {"Pk1": "Pe1",
"Pe1": ["Pe1k1", "Pe1k2", ...], "Pe1": ["Pe1k1", "Pe1k2", ...],
"Pk2": "Pk2", "Pk2": "Pk2",
...} ...}
``` ```
or better still, associated ordered dictionary mapping to a dictionary with or better still, associated ordered dictionary mapping to a dictionary with
```devices``` entry with a dictionary using nicknames: ```devices``` entry with a dictionary using nicknames:
``` ```
{"Pk1": "Pe1", {"Pk1": "Pe1",
"Pe1": {"devices": { "Pe1": {"devices": {
"Device1Nick": "Pe1k1", "Device1Nick": "Pe1k1",
"Device2Nick": "Pe1k2", ...} "Device2Nick": "Pe1k2", ...}
}, },
"Pk2": "Pk2", "Pk2": "Pk2",
...} ...}
``` ```
where: where:
* ```Pk1``` is the PK of user1, * ```Pk1``` is the PK of user1,
* ```Pe1``` is the PersonaID of user1, which could be the public signing key 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, * ```["Pe1k1", "Pe1k2", ...]``` are the PKs of each of the devices of user1,
delivered in a blob signed by ```Pe1`` delivered in a blob signed by ```Pe1``
Richer formats for the table are obviously possible, but we want to Richer formats for the table are obviously possible, but we want to
maintain a structure that foresees this table being managed by a maintain a structure that foresees this table being managed by a
keyring manager like ```keepassxc```. keyring manager like ```keepassxc```.
## MultiDevice Announcements Push ## MultiDevice Announcements Push
So if we modify the library and clients as described above, how do we 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 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 PersonaID, how is the library code table of PersonaID to ToxPk mapping
updated? We want this to be mainly automatic without bothering the user. 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 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 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: 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 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 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 in JSON or YAML, like we do with avatars, with the filename being named
```PersonaID.json```. ```PersonaID.json```.
Again, we want to maintain a structure that foresees this table being Again, we want to maintain a structure that foresees this table being
managed by a keyring manager like ```keepassxc```. It would not be managed by a keyring manager like ```keepassxc```. It would not be
saved in a profile, as this table spans multiple profiles. 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 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 his PersonaID by setting it to the friend's public key - the entry in
the table is a string. the table is a string.
We will call "a blob" the information that will update our PersonaID 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 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? 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, 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. 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. 3. We might push it as a DHT announcement.
Some clients may let the user decide whether of not to accept a blob Some clients may let the user decide whether of not to accept a blob
update when it arrives. update when it arrives.
## MultiDevice Announcements Blob ## MultiDevice Announcements Blob
So what is the blob of information that is pushed? So what is the blob of information that is pushed?
It has these characteristics: It has these characteristics:
1. It has 3 things - a name and a payload, and a NaCl signature. 1. It has 3 things - a name and a payload, and a NaCl signature.
2. It is small - 1K to 4K in size. 2. It is small - 1K to 4K in size.
3) As we will need a NaCl signing keypair in order to sign the payload, 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 - the name, (PersonaID) can be the public key of the signing keypair -
32 bytes or 64 hex chars. 32 bytes or 64 hex chars.
4. If we push the blob info by DHT announcements, it pushed regularly 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. 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 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 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. 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, 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. 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 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 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 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 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. 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 If we use DHT announcements, each client would watch the stream for
blobs named the PersonaID that they are interested in, which they know blobs named the PersonaID that they are interested in, which they know
from the public signing key being in the status message of the from the public signing key being in the status message of the
friends. Pushing the blob through DHT announcements would mean that friends. Pushing the blob through DHT announcements would mean that
the PersonaID to ToxPk mapping could be accessed even by people who 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 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 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 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 Persona could open the blob to get the update. Hence this encryption
is different from most Tox encryption in that multiple keys can open 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 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 enough for the blob to be signed, and that would be a good starting
point - add encryption later if needed. point - add encryption later if needed.
The public signing key could be put into the status message field of 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 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 status message on each of his devices, then that signing PK can become
the PersonaID. The mapping table can be automatically scanned and any the PersonaID. The mapping table can be automatically scanned and any
entries for which the PersonaID == ToxPk could be automatically entries for which the PersonaID == ToxPk could be automatically
updated to use the signing key as the PersonaId. updated to use the signing key as the PersonaId.
I had assumed we would have to use the DHT to deal with decentralization. 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 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. 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. 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 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 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 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 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 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. 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? 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, 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 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 morphed from the avatar code. Or you could push a blob as a file if
it got too big for a status message. it got too big for a status message.
The same blob would be on each of a Person's devices. The same blob would be on each of a Person's devices.
### Use the status message if less than 1007 bytes ### Use the status message if less than 1007 bytes
With the signature and the public key, this should leave room for at With the signature and the public key, this should leave room for at
least 12 devices in less than 1007 bytes, compressed and base64 least 12 devices in less than 1007 bytes, compressed and base64
encoded. With 1007 bytes with the signature and signing key, and encoded. With 1007 bytes with the signature and signing key, and
nicknames of 12 bytes it will take about 16 nicknames of 12 bytes it will take about 16
devices: ```1007-128-64-2/(32+6+12) = 16``` devices: ```1007-128-64-2/(32+6+12) = 16```
One problem with this is that only your Friends could verify the blob, 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, which means users you have never invited will not be able to verify,
unless they had the signing public key independently (perhaps using unless they had the signing public key independently (perhaps using
/sendfile). But perhaps that's good. Clients could watch status /sendfile). But perhaps that's good. Clients could watch status
message changes easily using the status_message callback. message changes easily using the status_message callback.
### It can be pushed as files like avatars amongst Friends ### It can be pushed as files like avatars amongst Friends
All the avatar code could be repurposed to also handle blobs, with the 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 signing public key put into the Person's status message. Avatars are
simple file transfers; there is a WHOLE byte dedicated for "file_kind", 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 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 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. 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 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 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. 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 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 ToxIDs. The code could accept either ToxPks or ToxIds, distinguishing
by length. Or you could just require that the Person already be a 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. 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 (The blob might be a signed way of associating nicknames with Pks if
we use associated ordered dictionary mapping to a dictionary with nicknames.) we use associated ordered dictionary mapping to a dictionary with nicknames.)
The clients would manage this seamlessly to aggregate the ToxPks The clients would manage this seamlessly to aggregate the ToxPks
together under one Persona that is shown to the user. The library does 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 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 pointing from PersonaID to the new list of ToxPks (devices) with the
first one being the active one. first one being the active one.
The generation and signing verification of the blobs could be done The generation and signing verification of the blobs could be done
outside of the clients in a utilty common to all clients. The clients 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. let a user push a blob whenever he wants - like when he changes devices.
## MultiDevice Profiles ## MultiDevice Profiles
In order for MultiDevice to work, we need to bootstrap a new devices from an 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. 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. 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 <https://git.plastiras.org/emdee/tox_profile> See <https://git.plastiras.org/emdee/tox_profile>
## MultiDevice Groups ## MultiDevice Groups
Previously, we described how we simply copy a profile to a new devices Previously, we described how we simply copy a profile to a new devices
and change the public/private keys as a starting point. and change the public/private keys as a starting point.
But we are left with as special problem with NGC groups. But we are left with as special problem with NGC groups.
The code is assumed to have been modified to handle Personas and, at 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 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. 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 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 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 being copied onto a new device is the profile of the founder, then
this key would need to be updated too. this key would need to be updated too.
Besides the group keypair in #L351-2 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_public_key, EXT_PUBLIC_KEY_SIZE); // 1
* bin_pack_bin(bp, chat->chat_secret_key, EXT_SECRET_KEY_SIZE); // 2 * 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 The chat->chat_secret_key is all zeros, I assume in everyone but the founder's
profile. profile.
It seems also that self's group keypair are saved to the group: It seems also that self's group keypair are saved to the group:
* self_public_key #L353 * self_public_key #L353
* self_secret_key #L354 * self_secret_key #L354
Do these keys have to be updated with the new keypair of the new 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 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 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 which case, the notion of the blob needs extending from just the
ToxPks and nicknames of each of the devices, to include the secret ToxPks and nicknames of each of the devices, to include the secret
keys of that Persona for each NGC group the Persona belongs to. 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 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 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 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, of the NGC group known as group_nick when I used those profiles? If so,
the Persona should have dictionarys for each group, with the Persona should have dictionarys for each group, with
```group_nick```, ```self_public_key``` and ```self_secret_key``` in each. ```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 ( 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 should be managed by a keymanager. In a corporate setting, this will
be a requirement. ) be a requirement. )
There is a Python script to parse profiles that could be modified to rekey 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 group self entries at: https://git.plastiras.org/emdee/tox_profile
## Future Directions ## Future Directions
If Personae identify which are your devices, it opens the possibility that If Personae identify which are your devices, it opens the possibility that
clients could treat incoming messages from one of your devices differently. clients could treat incoming messages from one of your devices differently.
Instead of simply displaying the message in a window, the client might 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, 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 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; from one of your devices. Automated file transfer, DoorSpy, history sync;
the possibilities are endless. the possibilities are endless.
## Summary ## Summary
The changes to the core are not large: The changes to the core are not large:
1. Change the status message callback to look for public signing keys 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 2. Change the status message callback to look for blobs as a first
implementation, and then later extend the avatar file transfer mechanism implementation, and then later extend the avatar file transfer mechanism
to transfer blobs to transfer blobs
3. Use the public signing keys to verify the blobs. This a NaCl call. 3. Use the public signing keys to verify the blobs. This a NaCl call.
4. Store the blobs in a subdirectory, with their signature. 4. Store the blobs in a subdirectory, with their signature.
5. Use the blobs to populate the table, and designate one entry as active. 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. 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. 7. Update the tables, if files are deleted from the ```Persona``` directory.
All existing unmodified users would continue to work: no testnet required. All existing unmodified users would continue to work: no testnet required.
Assuming the blobs were created by an independent stand alone utility, Assuming the blobs were created by an independent stand alone utility,
the changes to the clients are not large: the changes to the clients are not large:
1. Consult the mapping table and show it to the users. 1. Consult the mapping table and show it to the users.
2. Accept or reject new blob updates. 2. Accept or reject new blob updates.
3. Redefine the notion of contacts to point to the PersonaID. 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. 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. 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. We need to resolve the questions about having the same groups Personae.

96
QToxGreen.md

@ -1,48 +1,48 @@
Up: [[Home]] Up: [[Home]]
# Anthony Bilinski # Anthony Bilinski
## Zoominfo LinkedIn ## Zoominfo LinkedIn
Works full time as: Works full time as:
> C Software Engineer & Open Source Project Application > C Software Engineer & Open Source Project Application
> Developer & Firmware Maintainer & Developer at Avigilon > Developer & Firmware Maintainer & Developer at Avigilon
* https://www.zoominfo.com/p/Anthony-Bilinski/628037601 * https://www.zoominfo.com/p/Anthony-Bilinski/628037601
* https://ca.linkedin.com/in/anthony-bilinski-b4178611a (archive: https://archive.ph/X6Tsy ) * https://ca.linkedin.com/in/anthony-bilinski-b4178611a (archive: https://archive.ph/X6Tsy )
* https://www.zoominfo.com/p/Anthony-Bilinski/3246706849 * 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? 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 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. ```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. 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 ## Website
His web site no longer responds https://www.abilinski.com/ His web site no longer responds https://www.abilinski.com/
It was just a one page pointing to a ToxId It was just a one page pointing to a ToxId
* https://web.archive.org/web/20180825193239/https://www.abilinski.com/ * https://web.archive.org/web/20180825193239/https://www.abilinski.com/
His BS nodes no longer respond: His BS nodes no longer respond:
* tox.abilinski.com * tox.abilinski.com
* tox2.abilinski.com * tox2.abilinski.com
There is no github activity since July: There is no github activity since July:
* https://github.com/qtox/qtox * https://github.com/qtox/qtox
* https://github.com/anthonybilinski * https://github.com/anthonybilinski
## Funding ## Funding
Nothing on reddit.com in the last 6 months: Nothing on reddit.com in the last 6 months:
* https://www.reddit.com/user/Anthony_Bilinski * https://www.reddit.com/user/Anthony_Bilinski
Posted a [blog that announced he had a year's funding](<https://qtox.github.io/blog/2022/02/15/full-time) Posted a [blog that announced he had a year's funding](<https://qtox.github.io/blog/2022/02/15/full-time)
in February, but no idea who is the sponsor. It looks like `sphaerophoria` sponsored anthony? https://github.com/sphaerophoria?achievement=public-sponsor&tab=achievements in February, but no idea who is the sponsor. It looks like `sphaerophoria` sponsored anthony? https://github.com/sphaerophoria?achievement=public-sponsor&tab=achievements
But the licence for file for [toxext](https://github.com/toxext/toxext/), But the licence for file for [toxext](https://github.com/toxext/toxext/),
a sphaerophoria project initialy came from a sphaerophoria project initialy came from
[anthonybilinski/add-licence](https://github.com/toxext/toxext/commits?author=sphaerophoria) so they may be the same person. [anthonybilinski/add-licence](https://github.com/toxext/toxext/commits?author=sphaerophoria) so they may be the same person.

30
SecurityVulnerabilities.md

@ -1,15 +1,15 @@
Previous: [[Home]] Previous: [[Home]]
* [[UseGroupPasswordThroughAKDF]] * [[UseGroupPasswordThroughAKDF]]
* [[VulnerabilitiesInTheToxOnion]] * [[VulnerabilitiesInTheToxOnion]]
* [[DDosSmallNumberOfBSNodes]] * [[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). * 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: ##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 * [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: [[ToxComparedWithOtherIm]]
See also: <https://github.com/TokTok/c-toxcore/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity> See also: <https://github.com/TokTok/c-toxcore/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity>

169
ToxAndTorInChinaAndIran.md

@ -1,77 +1,92 @@
Up: [[Home]] Up: [[Home]]
From: https://github.com/TokTok/c-toxcore/issues/419 From: https://github.com/TokTok/c-toxcore/issues/419
I don't think indistinguishable message bytes and sizes are going to 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. 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 And anyone operating in a hostile environment is probably already
running Tox over Tor, which works well. running Tox over [Tor](https://www.torproject.org/download), which works well.
Did the reports of blocking in China include blocking over Tor? Tor Did the reports of blocking in China include blocking over Tor?
itself has implemented pluggable transport mechanisms that are Tor itself has implemented pluggable transport mechanisms that are
continuously being improved, and these include ways to make the continuously being improved, and these include ways to make the
traffic look like another protocol like HTTP or whatever: traffic look like another protocol like HTTP or whatever:
<https://snowflake.torproject.org/> <https://snowflake.torproject.org/>
So the best way to handle this may be to improve the documentation in 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). 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) 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. 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 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 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 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 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. 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. 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 There is a way of configuring a Tor client to uniquely assign a
(VirtualAddrNetworkIPv4) to each onion address it sees: life-of-the-tor-instance IPv4 address from a predefined private range
```AutomapHostsOnResolve 1```. So Tox could use OnionV3 BS nodes in a (VirtualAddrNetworkIPv4) to each onion address it sees:
properly configured Tor with just some properly configured BS hosts lists ```AutomapHostsOnResolve 1```. So Tox could use OnionV3 BS nodes in a
(if enough BS nodes provided OnionV3 addresses). Then we could leave properly configured Tor with just some properly configured BS hosts lists
the heavy lifting of the cat-and-mouse games of pluggable transports etc. (if enough BS nodes provided OnionV3 addresses). Then we could leave
to Tor (or i2p), and not try to chase them ourselves. the heavy lifting of the
[cat-and-mouse games](https://github.com/guardianproject/orbot/issues/742)
If you have such a list of onion addresses, the Tor user, who is running of pluggable transports etc. to Tor, and not try to chase them ourselves.
a Tor instance anyway to connect with the Tox client, adds this to the
```/etc/tor/torrc``` 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 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 Then with the list of onion addresses for BS nodes that are running Tox as OnionV3,
good-for-you-only IP addresses of OnionV3 BS nodes in IPv4. So the Tox user then you can use ```tor-resolve``` or ```tor-resolve -4``` to get the
does this and puts these addresses into his ```DHTnodes.json``` and boostraps his good-for-you-only IP addresses of OnionV3 BS nodes in IPv4. So the Tox user
Tox client over Tor Onions. This works with libtoxcore is it is today, as long as does this and puts these addresses into his ```DHTnodes.json``` and boostraps his
your client doesn't suffer from the dreaded deranged-hard-coded-bs syndrome. 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 These steps would be automated by a simple bash or Python script, perhaps a
good for life of the Tor instance, and the script would need rerunning when Tor Python script wrapped into an exe for Windows/Android. These addresses are
is restarted. You can also get the IPv4 address of each Onion BS node, good for life of the Tor instance, and the script would need rerunning
(for-life-of-the-tor-instance which is usually long enough) when Tor is restarted. You can also get the IPv4 address of each Onion BS node,
in Python using the Tor stem library. (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. The best thing we can do is to make these instructions available with
For UDP you can send a packet of len 78 with the magic first bytes and get a Tox downloads, and to ensure that all distributions of Tox come with
version and MOTD reply. Not so for TCP ( ```tor-resolve``` on all platforms. I doubt it comes with
in fact if you do send such a packet to the TCP it send the BS node into an [Orbot on Android](https://github.com/guardianproject/orbot/releases)
[infinite loop for which it neverrecovers](https://github.com/TokTok/c-toxcore/issues/2332)). and I doubt it comes with [Tor](https://www.torproject.org/download/) or
So we need a simple fix to the TCP_server code to at least look for a [Torbrowser on Windows](https://www.torproject.org/download/).
special packet like this and be nice and send a simple nice reply like We could ask the maintainers of
the UDP case. Raised as https://github.com/TokTok/c-toxcore/issues/2331 [TRIfA](https://f-droid.org/en/packages/com.zoffcc.applications.trifa/) and
[aTOX](https://f-droid.org/en/packages/ltd.evilcorp.atox) to include
We should not kid ourselves that we don't all live in China or Iran - it in their distributions, and it would be simple for us to compile a version
the planet is in a loc$down, and I think we might quickly find out just of ```tor-resolve``` for our packages to make sure it is available to our users.
how much resiliance we need. s/China/Iran/Syria/Russia/GDR It's a static utility that rarely changes.
* https://www.themoscowtimes.com/2021/12/07/why-the-kremlin-blocking-tor-is-a-big-deal-a75751 I've tried this but it's currently impossible to test as there is no equivalent
* https://www.wired.com/story/russia-block-tor-censorship/ to the ```other/fun/bootstrap_node_info.py``` script for TCP connections.
* https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook For UDP you can send a packet of len 78 with the magic first bytes and get a
* https://www.lifesitenews.com/news/biden-executive-order-allows-spying-on-americans-to-assess-political-instability-climate-threats/ 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
Up: [[DDosSmallNumberOfBSNodes]] [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]]

134
ToxComparedWithOtherIm.md

@ -1,68 +1,68 @@
Up: [[SecurityVulnerabilities]] Up: [[SecurityVulnerabilities]]
# Tox Compared With Other IM software # Tox Compared With Other IM software
## DeCentralized ## DeCentralized
### richochet ### richochet
Always uses Tor, rather than Tox, where Tor can be used at will. Always uses Tor, rather than Tox, where Tor can be used at will.
* <https://richochet.im> https: certificate expired over a year ago, and latest version in 2016. * <https://richochet.im> https: certificate expired over a year ago, and latest version in 2016.
* <https://github.com/ricochet-im/ricochet> last updated 2017. * <https://github.com/ricochet-im/ricochet> last updated 2017.
Relaunched as <https://github.com/blueprint-freespeech/ricochet-refresh> Relaunched as <https://github.com/blueprint-freespeech/ricochet-refresh>
* no group chat * no group chat
* can't use system Tor - only its own * can't use system Tor - only its own
* didn't see any mobile apps * 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) * 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 ### briar
* https://briarproject.org/ * https://briarproject.org/
* https://code.briarproject.org/briar/briar-desktop/ * https://code.briarproject.org/briar/briar-desktop/
Features: Features:
* Peer-to-peer encrypted messaging and forums * Peer-to-peer encrypted messaging and forums
* Messages are stored securely on your device, not in the cloud * Messages are stored securely on your device, not in the cloud
* Connect directly with nearby contacts - no Internet access required * Connect directly with nearby contacts - no Internet access required
* written in Java * written in Java
* Uses Tor. * Uses Tor.
* has an [Android](https://briarproject.org/installing-briar-via-f-droid/) app and desktop (the app is more featured than the desktop) * 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 * No support for Windows and macOS
* chats and groupchats * chats and groupchats
* [Well documented](https://code.briarproject.org/briar/briar/-/wikis/home) * [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" * [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 * 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." * The apps are betas that expire in 90 days: "For security reasons, their accounts and data will expire with the beta."
### ZeroNet ### ZeroNet
* Abandonned by its creator, it is being carried on by a number of * Abandonned by its creator, it is being carried on by a number of
non-cooperating forks. non-cooperating forks.
* A known RCE vulnerability is in some of the forks, but the developers * A known RCE vulnerability is in some of the forks, but the developers
of the patched forks have not filed a CVE. of the patched forks have not filed a CVE.
* None of the current developers have write access to the main web site, * None of the current developers have write access to the main web site,
which distributes code with the CVE. which distributes code with the CVE.
## Centralized ## Centralized
Centralized systems make it easy to MITM the E2E crypto, so unless they Centralized systems make it easy to MITM the E2E crypto, so unless they
are open source, they can't be trustworthy. are open source, they can't be trustworthy.
It is *much* harder to Tox over Tor than to block services like It is *much* harder to Tox over Tor than to block services like
WhatsApp which relay on centralized servers. WhatsApp which relay on centralized servers.
### WhatsApp ### WhatsApp
* https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security * https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security
## Signal ## Signal
[Signal](https://dt.gl/the-2021-review-of-messaging-service-providers-movim/) [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, 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 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. [Cloudflare](https://dt.gl/cloudflare-why-the-fuss/) which makes in unusable with Tor.

636
ToxMultiDevice.md

@ -1,318 +1,318 @@
# Toxcore Multi-Device Support Design Proposal # Toxcore Multi-Device Support Design Proposal
<https://docs.google.com/document/d/1op6zGR0KYdF7tTWSSX79KQieJu30vLZ6XG327kIBhxQ/> <https://docs.google.com/document/d/1op6zGR0KYdF7tTWSSX79KQieJu30vLZ6XG327kIBhxQ/>
To be a useable communication system, Tox needs to support multiple To be a useable communication system, Tox needs to support multiple
devices per user. This is the [TokTok](https://toktok.ltd) proposal. devices per user. This is the [TokTok](https://toktok.ltd) proposal.
## Objective ## Objective
This proposal is an RFC for a possible implementation of multi-device This proposal is an RFC for a possible implementation of multi-device
support for the Toxcore Messenger system. With the goal of replacing support for the Toxcore Messenger system. With the goal of replacing
Skype we must come close to feature parity, as well as ease of 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 use. Currently Tox clients need to share a ToxID. This ID inhibits
connecting with existing friends as it is only well-suited to machine connecting with existing friends as it is only well-suited to machine
reading. 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 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 The following implementation requires some additional features to be
added to Toxcore. These features have been requested before; however, added to Toxcore. These features have been requested before; however,
the goal of this implementation is to add Multi-Device support the goal of this implementation is to add Multi-Device support
only. The additional APIs that would be required (see next section) only. The additional APIs that would be required (see next section)
would only need to be minimal implementations to get multi-device would only need to be minimal implementations to get multi-device
working. And while their feature set should be expanded, that’s not working. And while their feature set should be expanded, that’s not
the goal of this implementation. the goal of this implementation.
## Background ## Background
ToxID’s are difficult to share without having an existing textual ToxID’s are difficult to share without having an existing textual
communication connection (anything you can copy from or paste communication connection (anything you can copy from or paste
to). Sharing ToxID’s in other ways is problematic. to). Sharing ToxID’s in other ways is problematic.
When it comes to multi-device support, at the present time we are When it comes to multi-device support, at the present time we are
lagging behind well-known centralized messenger systems. A few lagging behind well-known centralized messenger systems. A few
examples are Google Hangouts, Facebook Messenger, and Skype. Every one examples are Google Hangouts, Facebook Messenger, and Skype. Every one
of these syncs messages to every device which connects to their 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 network. If you need an address, number, or entire friend list it’s a
simple login away. simple login away.
Not the goal of this project but an important benefit, Multi-Device 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 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 the clients to connect with mobile devices (NFC, QR codes, other) and
be available anywhere. be available anywhere.
## Prerequisites ## Prerequisites
### Data Syncing (Friends and Messages): ### 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] 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 ### Contact Syncing
Contacts (called friends in the Toxcore API) are synced across all Contacts (called friends in the Toxcore API) are synced across all
devices using a transactional method. As a pair the devices decide devices using a transactional method. As a pair the devices decide
which will have the primary role, and which will take secondary. which will have the primary role, and which will take secondary.
hroughout the entire syncing process, the primary device will send hroughout the entire syncing process, the primary device will send
it’s data, followed by a “done” packet. The secondary will then 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 its data, followed by its own “done” packet. The primary device will
then send a “commit” packet, and will then commit the data from then send a “commit” packet, and will then commit the data from
temporary storage, into active use. Once receiving the “commit” temporary storage, into active use. Once receiving the “commit”
packet, the secondary device will do the same. packet, the secondary device will do the same.
Either Client can send an Error packet at either time, which will then Either Client can send an Error packet at either time, which will then
Message ordering Message ordering
Devices may sync out of order, but messages need to be consistently Devices may sync out of order, but messages need to be consistently
ordered. To simplify this, messages will be separated into “connection ordered. To simplify this, messages will be separated into “connection
sessions”, each getting a pseudorandom tox_session_ID. Messages will 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 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 will be the elapsed seconds from the start of the tox instance’s first
current connection to that peer. current connection to that peer.
Each session will be identified by a pseudo-unique hash from the Each session will be identified by a pseudo-unique hash from the
previous connect that included a confirmed message receipt. This will previous connect that included a confirmed message receipt. This will
ensure that both sessions and messages are ordered correctly once each ensure that both sessions and messages are ordered correctly once each
client is completely synced. (Optionally robust verifiability can be client is completely synced. (Optionally robust verifiability can be
gained by a git style hash of the x parent sessions) gained by a git style hash of the x parent sessions)
### Pseudo-unique Message IDs ### Pseudo-unique Message IDs
#### Update #### 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); 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 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); 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 Required for syncing messages between friends * devices. Each message
would include a message_id that would increment with each message. and would include a message_id that would increment with each message. and
reset with each new tox_instance (starting message ID is currently reset with each new tox_instance (starting message ID is currently
undecided). Messages id sections would have to be grouped by a client undecided). Messages id sections would have to be grouped by a client
coming online or going offline. These are per friend, per coming online or going offline. These are per friend, per
connection. And would be the same when sending the same message to connection. And would be the same when sending the same message to
multiple devices of a single friend. multiple devices of a single friend.
Each of these are pending an implementation spec. But are self-evident Each of these are pending an implementation spec. But are self-evident
in their use and general implementation. in their use and general implementation.
## 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. 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
Device IDs need to be unique and never changing. On each connect, each 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 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 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 for the deviceID at ```__device0```. If there is a device at that
address; then enumerate for each other device. Devices will be found address; then enumerate for each other device. Devices will be found
by the string_to_id service using the protected `__device[0-9]+` by the string_to_id service using the protected `__device[0-9]+`
group. (Toxcore must protect strings that start with two underscores group. (Toxcore must protect strings that start with two underscores
such as “__[string]”, and not allow a client to use them in the such as “__[string]”, and not allow a client to use them in the
string_to_id API.) string_to_id API.)
Starting with ```__device0```, the client will attempt to resolve the Starting with ```__device0```, the client will attempt to resolve the
ToxID at each incrementing ```__device#```. Once a ```__device#``` ToxID at each incrementing ```__device#```. Once a ```__device#```
returns empty, the client should stop. Each ```__device#``` string returns empty, the client should stop. Each ```__device#``` string
should be queried separately, ideally in a pseudo-random order to should be queried separately, ideally in a pseudo-random order to
prevent clear text attacks on the encryption. {under discussion} For prevent clear text attacks on the encryption. {under discussion} For
each ToxID at each ```__device#``` the client must add them to their 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 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 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 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 be in an unsecure state, and shouldn’t send any messages to any of the
devices. 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. 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 To enhance security once a ```__device#``` (number) is taken by a
device, that ```__device#``` must always resolve to either the same device, that ```__device#``` must always resolve to either the same
ToxID, or to all zeroes [0] if the device has been removed from the 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 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 uninstalling the Tox client. Toxcore will maintain a local list of
each device for each user, changes to a ```__device#``` will be each device for each user, changes to a ```__device#``` will be
assumed to be an impersonation attack. Removed devices will still keep assumed to be an impersonation attack. Removed devices will still keep
their ```__device#```, but that ```__device#``` will instead resolve their ```__device#```, but that ```__device#``` will instead resolve
to zeros. A string of zeros signifies that there was a device, but it to zeros. A string of zeros signifies that there was a device, but it
was removed intentionally. A ```__device#``` once resolved to zeros, was removed intentionally. A ```__device#``` once resolved to zeros,
must never change back to a ToxID. must never change back to a ToxID.
To remove or add a device, you will tell toxcore to add the device at 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 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 to that device and verify that it also wants to connect to the
existing device group. Once accepted, the toxcore instance on the existing device group. Once accepted, the toxcore instance on the
primary device will assign a ```__device#``` to the new device, and 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 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 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 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 friend/contact list, and the selected amount of history text history
to the new device. to the new device.
A max limit of devices will need to be chosen later to limit worst A max limit of devices will need to be chosen later to limit worst
case usage of enumerating devices. (Additional protocol requirements case usage of enumerating devices. (Additional protocol requirements
will be detailed later, i.a. security limitations, verifiable, master will be detailed later, i.a. security limitations, verifiable, master
device, slave device, deauthed devices.) device, slave device, deauthed devices.)
## Message sending ## Message sending
When a client sends a message to a friend/user, Toxcore will only 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 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 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 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 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 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 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 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 those 3 devices. Toxcore will only have to verify that one client
received the message, and may stop. This will protect the sender from 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 having to maintain a list of who needs what message, and leave the
additional data syncing up to the receiving client. additional data syncing up to the receiving client.
It is considered the job of the receiving client to keep all the other It is considered the job of the receiving client to keep all the other
devices in sync with the rest of the group. devices in sync with the rest of the group.
### Alternatives Considered ### Alternatives Considered
1. Not supporting multi-device (separate friends in the contact list for each device). 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. * 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. 2. Sharing the private key of a single ToxID to multiple devices.
* Non starter. Security nightmare. * Non starter. Security nightmare.
* Requires protocol rewrite. * Requires protocol rewrite.
3. [[GroupOfDevicesPOC]] 3. [[GroupOfDevicesPOC]]
4. [[MultiDeviceAnnouncementsPOC]] 4. [[MultiDeviceAnnouncementsPOC]]
### Unsolved Issues ### Unsolved Issues
How will messages be hashed to generate the seed for the message ID? How will messages be hashed to generate the seed for the message ID?
Effective and secure history syncing across devices. Effective and secure history syncing across devices.
How to add a user to your contact list How to add a user to your contact list
* By Primary ToxID(f)[^6](g)[^7] * By Primary ToxID(f)[^6](g)[^7]
* By any deviceID * By any deviceID
* Something else? * Something else?
## Roadmap ## Roadmap
1. Unique message IDs 1. Unique message IDs
1. incrementing numbers 1. incrementing numbers
2. delta-from last 2. delta-from last
2. Device network 2. Device network
1. deviceID vs toxID 1. deviceID vs toxID
2. Adding a device 2. Adding a device
3. Removing a device 3. Removing a device
4. Sending a message to more than one device 4. Sending a message to more than one device
3. Syncing data 3. Syncing data
1. contact list 1. contact list
2. messages 2. messages
3. other? 3. other?
## Notes & FAQ: ## Notes & FAQ:
Conversations that need to be added to the spec: Conversations that need to be added to the spec:
``` ```
<nurupo> 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. <nurupo> 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.
<nurupo> will Alice see the file request on both clients? <nurupo> will Alice see the file request on both clients?
<grayhatter> the file request will go to all online devices <grayhatter> the file request will go to all online devices
<nurupo> ok, i'm not finished <nurupo> ok, i'm not finished
<grayhatter> then the file will get canceled / "marked as accpeted on a different device" <grayhatter> then the file will get canceled / "marked as accpeted on a different device"
<nurupo> so, Alice accepts and completes the file transfer on her phone <nurupo> so, Alice accepts and completes the file transfer on her phone
``` ```
(h)[^8] (i)[^9] (j)[^10] (h)[^8] (i)[^9] (j)[^10]
``` ```
<nurupo> i guess you answered what i wanted to know <nurupo> i guess you answered what i wanted to know
<nurupo> what if race condition happens? <nurupo> what if race condition happens?
<grayhatter> but I hadn't considered that detail... It'll break the existing file transfer API... <grayhatter> but I hadn't considered that detail... It'll break the existing file transfer API...
<nurupo> Alice accepts files at the same time both on pc and phone? <nurupo> Alice accepts files at the same time both on pc and phone?
<grayhatter> nurupo, can't happen <grayhatter> nurupo, can't happen
<nurupo> why it can't happen? <nurupo> why it can't happen?
<grayhatter> 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 <grayhatter> 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
<grayhatter> 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 <grayhatter> 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
<nurupo> what if Alice accepts a file on another device before it gets the cancel message? <nurupo> what if Alice accepts a file on another device before it gets the cancel message?
<grayhatter> it'll show inprogress on that device, with 0 transfer, then toxcore on the sending device will still send the cancel to that device <grayhatter> it'll show inprogress on that device, with 0 transfer, then toxcore on the sending device will still send the cancel to that device
<nurupo> Bob will get two accepts from two devices of Alice? <nurupo> Bob will get two accepts from two devices of Alice?
<grayhatter> yes, but it will ignore the 2nd <grayhatter> yes, but it will ignore the 2nd
<nurupo> how it knows which to ignore? <nurupo> how it knows which to ignore?
<grayhatter> (I'm saying all of this from what my plans are, I haven't even started on filetransfers yet) <grayhatter> (I'm saying all of this from what my plans are, I haven't even started on filetransfers yet)
<grayhatter> psudo code -> <grayhatter> psudo code ->
<nurupo> 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 <nurupo> 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
<grayhatter> OH <grayhatter> OH
<grayhatter> bob will in that case cancel the phone then <grayhatter> bob will in that case cancel the phone then
``` ```
(k)[^11] (k)[^11]
``` ```
<nurupo> fair enough <nurupo> fair enough
<grayhatter> no reason to make it more complicated then it needs to be <grayhatter> no reason to make it more complicated then it needs to be
``` ```
### Feature Requests: ### Feature Requests:
(Requested publicly, no suggestions have been reviewed or accepted yet.) (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 device id priority like with XMPP https://wiki.xmpp.org/web/Jabber_Resources
* Per status+deviceid priority, XMPP does that as well * Per status+deviceid priority, XMPP does that as well
* Ability to address device id explicitly * Ability to address device id explicitly
## Footnotes ## 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? * (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. * (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. 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. * (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. * (d)[^4] I'm likely to drop that idea in total.
Currently toxcore sends everything to all devices. 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. * (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. * (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 * (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 * (h)[^8] Does it make sense to think about sending the file to both
clients, if the user accepts on multiple devices? Especially for clients, if the user accepts on multiple devices? Especially for
bigger files or multiple recipients a P2P protocol (e.g. torrent) bigger files or multiple recipients a P2P protocol (e.g. torrent)
may be useful. may be useful.
* (i)[^9] Yeah, I've given that a little thought. The current idea * (i)[^9] Yeah, I've given that a little thought. The current idea
floating around has been to implement something torrent like inside floating around has been to implement something torrent like inside
group chats. Maybe we could use that as well? As far as multiple 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 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 accept, then let the other devices sync the file themselves. That
way the sender doesn't have to spend the extra data for the way the sender doesn't have to spend the extra data for the
receivers convenience. receivers convenience.
* (j)[^10] I like that idea. Especially if one thinks about those users * (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 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 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 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 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 just sending it once should be a lot easier. I'd consider media sync
between my devices as a nice-to-have. between my devices as a nice-to-have.
* (k)[^11] Could it be a good idea to allow sync incomplete downloaded * (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 files from device A to device B and then start downloading from device B

2
ToxNetworkResilience.md

@ -32,7 +32,7 @@ configuration:
# Tox hidden service configuration. # Tox hidden service configuration.
HiddenServiceDir /var/lib/tor/tox-hsv3/ HiddenServiceDir /var/lib/tor/tox-hsv3/
HiddenServicePort 3389 127.0.0.1:3389 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 assuming your Tor lib directory os ```/var/lib/tor```. In that subdirectory
you will find a file named ```hostname``` which is the ```.onion``` name you will find a file named ```hostname``` which is the ```.onion``` name

12
UseGroupPasswordThroughAKDF.md

@ -1,6 +1,6 @@
Up: [[SecurityVulnerabilities]] Up: [[SecurityVulnerabilities]]
Chatting with sudden6 (Sep 2022) says this still an open vulnerability. Chatting with sudden6 (Sep 2022) says this still an open vulnerability.
Use the group password only through a KDF by sudden6 Use the group password only through a KDF by sudden6
<https://github.com/JFreegman/toxcore/pull/27> <https://github.com/JFreegman/toxcore/pull/27>

18
VulnerabilitiesInTheToxOnion.md

@ -1,9 +1,9 @@
Up: [[SecurityVulnerabilities]] Up: [[SecurityVulnerabilities]]
Chatting with JF (Aug 2022) makes me think that these are still open: Chatting with JF (Aug 2022) makes me think that these are still open:
Known vulnerabilities in the tox onion: Known vulnerabilities in the tox onion:
* <https://github.com//zugz/tox-onionPathsProposal/blob/master/onionVulns.md> * <https://github.com//zugz/tox-onionPathsProposal/blob/master/onionVulns.md>
* <https://github.com/TokTok/c-toxcore/issues/1121> * <https://github.com/TokTok/c-toxcore/issues/1121>
[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. [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.

2
_Footer.md

@ -1 +1 @@
Up: [[Home]] Up: [[Home]]