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

Added ToxNetworkResilience.md

emdee 2022-10-11 10:10:20 +00:00
parent 52d1f5ff91
commit 550cfdb172
7 changed files with 84 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
Home.md

@ -1,24 +1,32 @@
# Welcome to the Wiki.
What I am noticing is that there is no notion of a Tox Improvement Proposal(TIP),
so ideas and vulnerabilities get forgotten in abandonned PRs in abandoned repos.
What I am noticing is that there is no notion of a Tox Improvement
Proposal(TIP), so ideas and vulnerabilities get forgotten in
abandonned PRs in abandoned repos, or ignored issues.
I suggested wiki.tox.chat as a place to identify and prioritize TIPs but maybe we can elaborate POCs here. I want to "argue" it out to get to the "best" proposal so work so work can get going on a trial version. developers who know the key exchange mechanisms can bring a lot of the existing codebase to bear on this problem, and resolve wrinkles in the concepts.
I suggested wiki.tox.chat as a place to identify and prioritize TIPs
but maybe we can elaborate POCs here. I want to "argue" it out to get
to the "best" proposal so work so work can get going on a trial
version. developers who know the key exchange mechanisms can bring a
lot of the existing codebase to bear on this problem, and resolve
wrinkles in the concepts.
### Multi-Device DHT announcements:
* [[MultiDevice Announcements POC]]
### Group-of-devices:
* [[GroupOfDevicesPOC]]
* Original TokTok ToxMultiDevice: [[ToxMultiDevice]]
### Original TokTok ToxMultiDevice:
* [[ToxMultiDevice]]
### [[SecurityVulnerabilities]]:
* [[UseGroupPasswordThroughAKDF]]
* [[VulnerabilitiesInTheToxOnion]]
* [[DDosSmallNumberOfBSNodes]]
### Network Resilience
* [[ToxNetworkResilience]]
### Security
* [[SecurityVulnerabilities]]:
** [[UseGroupPasswordThroughAKDF]]
** [[VulnerabilitiesInTheToxOnion]]
** [[DDosSmallNumberOfBSNodes]]

4
MultiDeviceAnnouncementsPOC.md

@ -7,7 +7,7 @@ usage of Tox with multiple devices is an urgent problem, as anyone
with mobiles runs into it, and all the competition software deals with it.
MultiDevice is much easier in centralized systems and our decentalization
is why it's hard for us; if we make it, we make be the first ever!
**Woke Warning:** gender specific, non-android/furry friendly grammar
is used throughout.
@ -303,7 +303,7 @@ the possibilities are endless.
The changes to the core are not large:
1. Change the status message callback to look for public signing keys
2. Change the status message callback to look for blobs as a first
2. Change the status message callback to look for blobs as a first
implementation, and then later extend the avatar file transfer mechanism
to transfer blobs
3. Use the public signing keys to verify the blobs. This a NaCl call.

16
QToxGreen.md

@ -5,17 +5,17 @@ Up: [[Home]]
## Zoominfo LinkedIn
Works full time as:
Works full time as:
> 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://www.zoominfo.com/p/Anthony-Bilinski/3246706849
So he's working on Open Source projects as his day job at Avigilon May 2016 - Sep 2021 - 5 years 5 months. Maybe qTox was his day job until Sept 2021?
Avigilon is a video surveillance hardware and software company founded in 2004, went public on the VSE and was bought out by Motorolla. His zoominfo listing gives
Avigilon is a video surveillance hardware and software company founded in 2004, went public on the VSE and was bought out by Motorolla. His zoominfo listing gives
```a***@curtiswright.com``` as his email. Curtiswright is a well know USGov contractor. He did an Internship at Curtis in 2014, so the @curtiswright email may not be current - an old zoominfo address.
His boss and colleague on the zoominfo.com list both check out. His boss was a [well-known Security Industry professional](https://www.sdmmag.com/articles/100828-security-industry-mourns-the-loss-of-matthew-krebs) not based in Canada.
@ -23,14 +23,14 @@ His boss and colleague on the zoominfo.com list both check out. His boss was a [
## Website
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/
His BS nodes no longer respond:
* tox.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/anthonybilinski
@ -44,5 +44,5 @@ in February, but no idea who is the sponsor. It looks like `sphaerophoria` spons
But the licence for file for [toxext](https://github.com/toxext/toxext/),
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.

2
SecurityVulnerabilities.md

@ -8,7 +8,7 @@ Previous: [[Home]]
##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]]

2
ToxComparedWithOtherIm.md

@ -9,7 +9,7 @@ Up: [[SecurityVulnerabilities]]
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://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>

20
ToxMultiDevice.md

@ -61,7 +61,7 @@ device will then send a “commit” packet, and will then commit the data
from temporary storage, into active use. Once receiving the “commit”
packet, the secondary device will do the same.
Either Client can send an Error packet at either time, which will then
Either Client can send an Error packet at either time, which will then
Message ordering
Devices may sync out of order, but messages need to be consistently
@ -108,8 +108,8 @@ Security and safety is the primary concern, however this needs to be tempered wi
### Device IDs
Device IDs need to be unique and never changing. On each connect, each client should query each friend they connect to, to verify if they support multi-device AND are in a group. This can be done by asking for the deviceID at ```__device0```. If there is a device at that address; then enumerate for each other device.
Devices will be found by the string_to_id service using the protected `__device[0-9]+` group. (Toxcore must protect strings that start with two underscores such as “__[string]”, and not allow a client to use them in the string_to_id API.)
Device IDs need to be unique and never changing. On each connect, each client should query each friend they connect to, to verify if they support multi-device AND are in a group. This can be done by asking for the deviceID at ```__device0```. If there is a device at that address; then enumerate for each other device.
Devices will be found by the string_to_id service using the protected `__device[0-9]+` group. (Toxcore must protect strings that start with two underscores such as “__[string]”, and not allow a client to use them in the string_to_id API.)
Starting with ```__device0```, the client will attempt to resolve the
@ -125,7 +125,7 @@ be in an unsecure state, and shouldn’t send any messages to any of the
devices.
The ```__device#``` list for every client must match exactly to what every other device reports. And each ```__device#``` once used must always resolve to that ID.
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
@ -153,7 +153,7 @@ friend/contact list, and the selected amount of history text history
to the new device.
A max limit of devices will need to be chosen later to limit worst case usage of enumerating devices. (Additional protocol requirements will be detailed later, i.a. security limitations, verifiable, master device, slave device, deauthed devices.)
A max limit of devices will need to be chosen later to limit worst case usage of enumerating devices. (Additional protocol requirements will be detailed later, i.a. security limitations, verifiable, master device, slave device, deauthed devices.)
## Message sending
@ -191,7 +191,7 @@ It is considered the job of the receiving client to keep all the other devices i
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
@ -222,7 +222,7 @@ Conversations that need to be added to the spec:
<nurupo> will Alice see the file request on both clients?
<grayhatter> the file request will go to all online devices
<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
```
(h)[^8] (i)[^9] (j)[^10]
@ -241,7 +241,7 @@ Conversations that need to be added to the spec:
<grayhatter> yes, but it will ignore the 2nd
<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> 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
<grayhatter> OH
<grayhatter> bob will in that case cancel the phone then
@ -268,14 +268,14 @@ Conversations that need to be added to the spec:
* [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.
* [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.
* [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.

41
ToxNetworkResilience.md Normal file

@ -0,0 +1,41 @@
Up: [[Home]]
Tox relies on "bootstrap" nodes to be able to find your Friends. That
list of nodes is quite small, < 100, and you can find it in the file
often called DHTnodes.json. If a country like Iran can block those
nodes, they can block Tox. Whether Tox is encrypted makes no difference
in their ability to block.
Tox works well over [Tor](https://torproject.org/), which should help.
If they can't block Tor, then they can't block Tox over Tor. And Tor
is evolving stratagies to help defeat blocking, like
[snowflake](https://torproject.org/). As Tor evolves its resillience
strategies, Tox over Tor evolves with it. It is *much* harder to block
Tox over Tor than to block services like WhatsApp which relay on
centralized servers, unless the service runs a OnionV3 Tor service
that makes if accesible directly over Tor.
Everyone who wants to help the network be resilient to blocking should
run their clients like [toxic](https://github.com/JFreegman/toxic/)
with the ```-T, --tcp-relay``` if they are not using Tor. Choose a
random port number ```> 10000 < 65000``` for the port.
If you are not running over Tor and are on a stable connection, try it.
Every BSnode operator who wants to help the network be resilient in
places like Iran should run a Tor server that provides the node as an
onionV3 service; see [[ToxAndTorInChina]].
If you run a bootstrap node, you can run a Tor Ononv3 gateway to the
node by simply adding the following lines to your ```torrc```
configuration:
```
# Tox hidden service configuration.
HiddenServiceDir /var/lib/tor/tox-hsv3/
HiddenServicePort 3389 127.0.0.1:3389
HiddenServicePort 3389 127.0.0.1:33446
```
assuming your Tor lib directory os ```/var/lib/tor```. In that subdirectory
you will find a file named ```hostname``` which is the ```.onion``` name
of your node, the Tor equivalent of your ToxId.