ffi-tox 0.1.1 → 0.1.3

data/ProjectTox-Core/dist-build/android-arm.sh

@@ -0,0 +1,3 @@
+#!/bin/sh
+export CFLAGS="-Ofast -mthumb -marm -march=armv6"
+TARGET_ARCH=arm TOOLCHAIN_NAME=arm-linux-androideabi-4.8 HOST_COMPILER=arm-linux-androideabi "$(dirname "$0")/android-build.sh"

data/ProjectTox-Core/dist-build/android-armv7.sh

@@ -0,0 +1,3 @@
+#!/bin/sh
+export CFLAGS="-Ofast -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -marm -march=armv7-a"
+TARGET_ARCH=armv7 TOOLCHAIN_NAME=arm-linux-androideabi-4.8 HOST_COMPILER=arm-linux-androideabi "$(dirname "$0")/android-build.sh"

data/ProjectTox-Core/dist-build/android-build.sh

@@ -0,0 +1,59 @@
+#!/bin/sh
+
+if [ -z "$ANDROID_NDK_HOME" ]; then
+    echo "You should probably set ANDROID_NDK_HOME to the directory containing"
+    echo "the Android NDK"
+    exit
+fi
+
+if [ -z "$SODIUM_HOME" ]; then
+    echo "You should probably set SODIUM_HOME to the directory containing root sodium sources"
+    exit
+fi
+
+if [[ -z $TARGET_ARCH ]] || [[ -z $HOST_COMPILER ]]; then
+    echo "You shouldn't use android-build.sh directly, use android-[arch].sh instead"
+    exit 1
+fi
+
+if [ ! -f ./configure ]; then
+	echo "Can't find ./configure. Wrong directory or haven't run autogen.sh?"
+	exit 1
+fi
+
+if [ -z "$TOOLCHAIN_DIR" ]; then
+  export TOOLCHAIN_DIR="$(pwd)/android-toolchain-${TARGET_ARCH}"
+  export MAKE_TOOLCHAIN="${ANDROID_NDK_HOME}/build/tools/make-standalone-toolchain.sh"
+  
+  if [ -z "$MAKE_TOOLCHAIN" ]; then
+    echo "Cannot find a make-standalone-toolchain.sh in ndk dir, interrupt..."
+    exit 1
+  fi
+  
+  $MAKE_TOOLCHAIN --platform="${NDK_PLATFORM:-android-14}" \
+                  --arch="${TARGET_ARCH}" \
+                  --toolchain="${TOOLCHAIN_NAME:-arm-linux-androideabi-4.8}" \
+                  --install-dir="${TOOLCHAIN_DIR}"
+fi
+
+export PREFIX="$(pwd)/toxcore-android-${TARGET_ARCH}"
+export SYSROOT="${TOOLCHAIN_DIR}/sysroot"
+export PATH="${PATH}:${TOOLCHAIN_DIR}/bin"
+
+# Clean up before build
+rm -rf "${PREFIX}"
+
+export CFLAGS="${CFLAGS} --sysroot=${SYSROOT} -I${SYSROOT}/usr/include"
+export CPPFLAGS="${CFLAGS}"
+export LDFLAGS="${LDFLAGS} -L${SYSROOT}/usr/lib"
+
+./configure --host="${HOST_COMPILER}" \
+            --with-sysroot="${SYSROOT}" \
+            --with-libsodium-headers="${SODIUM_HOME}/libsodium-android-${TARGET_ARCH}/include" \
+            --with-libsodium-libs="${SODIUM_HOME}/libsodium-android-${TARGET_ARCH}/lib" \
+            --disable-av \
+            --prefix="${PREFIX}" && \
+
+make clean && \
+make -j3 install && \
+echo "libtoxcore has been installed into ${PREFIX}"

data/ProjectTox-Core/dist-build/android-mips.sh

@@ -0,0 +1,3 @@
+#!/bin/sh
+export CFLAGS="-Ofast"
+TARGET_ARCH=mips TOOLCHAIN_NAME=mipsel-linux-android-4.8 HOST_COMPILER=mipsel-linux-android "$(dirname "$0")/android-build.sh"

data/ProjectTox-Core/dist-build/android-x86.sh

@@ -0,0 +1,3 @@
+#!/bin/sh
+export CFLAGS="-Ofast"
+TARGET_ARCH=x86 TOOLCHAIN_NAME=x86-4.8 HOST_COMPILER=i686-linux-android "$(dirname "$0")/android-build.sh"

data/ProjectTox-Core/docs/Group-Chats.md

@@ -0,0 +1,71 @@
+Massive public group chats.
+
+Note that not all this document has been implemented: only private (invite only) group chats are currently implemented.
+
+Everyone generates a short term public private key pair right before joining 
+the chat.
+
+Note that for public group chats it is impossible to protect the chat from 
+being spied on by a very dedicated attacker, encryption is therefor used as a 
+form of spam/access control.
+
+## Joining the chats
+
+
+## Protocol
+
+
+Node format: 
+See DHT, currently uses the IPv6 Node_format.
+
+Get nodes (Request):
+Packet contents: 
+```
+[char with a value of 48][Bob's (The receiver's) Public key (client_id) (32 bytes))][Alice's (The sender's) Public key (client_id) (32 bytes)][Random nonce (24 bytes)][Encrypted with the nonce, private key of the sender and public key of the receiver:[char with a value of 48][random 8 byte (ping_id)]
+```
+Valid replies: a send_nodes packet
+
+Send_nodes (response): 
+```
+[char with a value of 48][Bob's (The receiver's) Public key (client_id) (32 bytes))][Alice's (The sender's) Public key (client_id) (32 bytes)][Random nonce (24 bytes)][Encrypted with the nonce, private key of the sender and public key of the receiver:[char with a value of 49][random 8 byte (ping_id)][Nodes in node format, length=40 * (number of nodes (maximum of 6 nodes)) bytes]]
+```
+
+Broadcast packet:
+```
+[char with a value of 48][Bob's (The receiver's) Public key (client_id) (32 bytes))][Alice's (The sender's) Public key (client_id) (32 bytes)][nonce][Encrypted with the nonce, private key of the sender and public key of the receiver:[char with a value of 50][Data to send to everyone]]
+```
+
+
+Data to send to everyone:
+TODO: signing and spam control + permissions.
+[client_id of sender][uint32_t message number][char with a value representing id of message][data]
+
+Note: the message number is increased by 1 for each sent message.
+
+message ids:
+0 - ping
+sent every ~60 seconds by every peer.
+No data.
+
+16 - new_peer
+Tell everyone about a new peer in the chat.
+[uint8_t public_key[public_key_len]]
+
+17 - ban_peer
+Ban a peer
+[uint8_t public_key[public_key_len]]
+
+18 - topic change
+[uint8_t topic[topiclen]]
+
+48 - name change
+[uint8_t name[namelen]]
+
+49 - status change
+[uint8_t (status id)]
+
+64 - chat message
+[uint8_t message[messagelen]]
+
+65 - action (/me)
+[uint8_t message[messagelen]]

data/ProjectTox-Core/docs/Hardening.txt

@@ -0,0 +1,60 @@
+Currently an attacker with sufficient resources could launch a large scale 
+denial of service type attack by flooding the Tox network with a bunch of nodes 
+that do not act like real nodes to prevent people from finding each other. 
+
+Due to the design of Tox, this is the worst thing an attacker can do to disrupt 
+the network.
+
+This solution's goal is to make these denial of service attack very very hard 
+to accomplish.
+
+For the network to work every Tox node must:
+1. Respond to ping requests.
+2. Respond to get node requests with the ids of nodes closest to a queried id 
+(It is assumed each nodes know at least the 32 nodes closest to them.)
+3. Properly send crypto request packets to their intended destination.
+
+Currently the only thing a node needs to do to be part of the network is 
+respond correctly to ping requests. 
+
+The only people we really trust on the network are the nodes in our friends 
+list.
+
+
+The behavior of each Tox node is easily predictable. This means that it possible 
+for Tox nodes to test the nodes that they are connected to to see if they 
+behave like normal Tox nodes and only send nodes that are confirmed to behave 
+like real Tox nodes as part of send node replies when other nodes query them.
+
+If correctly done, this means that to poison the network an attacker can only 
+infiltrate the network if his "fake" nodes behave exactly like real nodes 
+completely defeating the purpose of the attack. Of course nodes must be 
+rechecked regularly to defeat an attack where someone floods the network with 
+many good nodes then suddenly turns them all bad.
+
+This also prevents someone from accidentally killing the tox network with a bad 
+implementation of the protocol.
+
+Implementation ideas (In Progress):
+
+1. Use our friends to check if the nodes in our close list are good.
+
+EX: If our friend queries a node close to us and it correctly returns our 
+ip/port and then sends a crypto request packet to it and it routes it correctly 
+to us then it is good.
+
+Problems with this: People don't always have at least one online friend.
+
+2. Pick random nodes (add ourselves some random (fake) friends to increase the 
+pool of available nodes) and make then send requests to other nodes, the 
+response is then relayed back to us and compared to how the node should have 
+behaved. If the node is found to be behaving correctly, it is set as trusted. 
+Only trusted nodes are sent in send node packets, that is unless the exact node 
+being queried for in the getnode packet is present, it will be sent in the 
+sendnode packet even if it is not trusted.
+
+The hypothesis is that if to be part of the network nodes have to behave 
+correctly it should prevent disruption from nodes that behave incorrectly.
+
+(This idea is currently being implemented in the harden branch.)
+...

data/ProjectTox-Core/docs/Hardening_docs.txt

@@ -0,0 +1,30 @@
+Hardening request packets are sent as crypto request packets (see crypto docs.)
+NOTE: currently only get nodes requests are tested in the code which is why 
+there is only one test (more will be added soon.)
+
+All hardening requests must contain exactly 768 bytes of data. (The data sent 
+must be padded with zeros if it is smaller than that.)
+
+1. Get the information (IP_port, client_id) of the node we want to test.
+2. Find a couple random nodes that is not that node (one for each test.)
+3. Send crypto request packets to each of these random nodes with the data being:
+
+[byte with value: 02 (get nodes test request)][struct Node_format (the node to 
+test.)][client_id(32 bytes) the id to query the node with.][padding]
+
+4. The random node receives a packet.
+-The packet is a get nodes test request:
+    send a get_node request to that node with the id to query in the request.
+    when a send_node response is received, send the following response to the 
+	person who sent us the get nodes test request packet:
+        [byte with value: 03 (get nodes test response)][client_id(32 bytes): 
+		the id of the tested node][The list of nodes it responded with in IPv6 
+		Node format (struct Node_Format)]
+    PROTIP: (get node requests and response contain an encrypted part that you 
+	can use to store information so that you don't 
+    have to store in your memory where/if to send back the response from the 
+	send node)
+
+5. Receive the test responses.
+-If the test(s) pass (the nodes behave in a satisfactory manner), make these 
+nodes have priority over those who don't pass the test(s).

data/ProjectTox-Core/docs/Prevent_Tracking.txt

@@ -0,0 +1,160 @@
+Current privacy issues with the Tox DHT: 
+
+1. It makes tracking people across different IPs very easy.
+Solution: Have each new DHT use a temporary public/private key pair not related 
+to the long term public/private key pair.
+
+2. Metadata on which key is friends to which can be collected (The hardening 
+makes this somewhat harder by introducing a bunch of random traffic but not 
+impossible.).
+Solution: If no long term keys were used in the DHT it would solve this 
+problem. (possibly knowing which ip is connected to which is much less 
+precious.)
+
+
+So, it seems all our privacy problems are solved if we can manage to make every 
+node in the DHT have a keypair that is not related to the long term keys and is 
+generated every session.
+
+
+So, every node in the DHT now has a temporary keypair not related to their real 
+long term one. 
+
+But, how do people find themselves then? We have to add a way for people to 
+tell their friends what their DHT public key is. We also have to somehow make 
+it so people can send/receive friend requests. This has to be done without 
+non-friends being able to find out where a node is.
+
+The solution: Onion routing + enable the storage of some small amount of data 
+on DHT nodes.
+
+
+Alice and bob are friends. Before joining the DHT they generate temporary 
+session keypairs to be used for the DHT instead of their long term keys.
+
+Bob finds a bunch of random nodes then picks 3 random working ones (A, B, C).
+
+Bob gets the known working node with an id closest to his real one from his list (D)
+
+Bob then creates an onion (the packet will go through A, B, C and will end up at D) 
+announce request packet with his real public key, ping_id as zeros and
+searching for his real public key.
+
+Bob will announce response packets and will recursively send onion announce request 
+packets to closer and closer nodes until he finds the ones closest to his real public key.
+
+Once he has done this, he will send some onion announce request packets with the right 
+ping_id previously received from the node when he queried it to announce himself to the node.
+
+The nodes he announces himself to keep the information to send onion packets to that node in 
+memory.
+
+Alice meanwhile searches for the nodes closest to Bobs real id using a temporary keypair and 
+announce request packets. She does this until she finds nodes that respond with a ping_id of zero.
+
+She sends data to route request packet with information telling Bob her temporary id in the DHT
+(or a friend request if she is not friends with him).
+
+Bob finds her by using her temporary id and they connect to each other.
+
+
+NOTE: crypto_box is used for all the asymmetric encryption and crypto_secretbox is used for all 
+the symmetric. Also every DHT node have a random symmetric key which they use to encrypt the stuff 
+in normal get node request that is used to encrypt stuff in the following.
+
+Onion packet (request):
+
+initial (sent from us to node A):
+
+[uint8_t packet id (128)][nonce]
+[our temp DHT public key]encrypted with our temp DHT private key and the pub key of Node A and the nonce:[ 
+[IP_Port of node B][a random public key]encrypted with the random private key and the pub key of Node B and the nonce:[ 
+[IP_Port of node C][a random public key]encrypted with the random private key and the pub key of Node C and the nonce:[ 
+[IP_Port of node D][data to send to Node D]]]]
+
+(sent from node A to node B):
+
+[uint8_t packet id (129)][nonce]
+[a random public key]encrypted with the random private key and the pub key of Node B and the nonce:[ 
+[IP_Port of node C][a random public key]encrypted with the random private key and the pub key of Node C and the nonce:[ 
+[IP_Port of node D][data to send to Node D]]][nonce (for the following symmetric encryption)]encrypted with temp symmetric key of Node A: [IP_Port (of us)]
+
+(sent from node B to node C):
+
+[uint8_t packet id (130)][nonce]
+[a random public key]encrypted with the random private key and the pub key of Node C and the nonce:[ 
+[IP_Port of node D][data to send to Node D]][nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node B:[IP_Port (of Node A)[nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node A: [IP_Port (of us)]]
+
+(sent from node C to node D):
+[data to send to Node D][nonce (for the following symmetric encryption)]encrypted with temp symmetric key of Node C:
+[IP_Port (of Node B)[nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node B:[IP_Port (of Node A)[nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node A: [IP_Port (of us)]]]
+
+Data sent to Node D:
+
+announce request packet:
+[uint8_t packet id (131)][nonce][our real long term public key or a temporary one (see next)]
+encrypted (with our real long term private key if we want to announce ourselves, a temporary one if we are searching for friends) and the pub key of Node D and the nonce:
+[[(32 bytes) ping_id][client id we are searching for][public key that we want those sending back data packets to use.][data to send back in response(fixed size)]]
+
+(if the ping id is zero, respond with a announce response packet)
+(If the ping id matches the one the node sent in the announce response and the public key matches the one being searched for, 
+add the part used to send data to our list (if the list is full make it replace the furthest entry))
+
+data to route request packet:
+[uint8_t packet id (133)][public key of destination node][nonce][temporary just generated public key]
+encrypted with that temporary private key and the nonce and the public key from the announce response packet of the destination node:[data]
+(if Node D contains the ret data for the node, it sends the stuff in this packet as a data to route response packet to the right node)
+
+The data in the previous packet is in format: [real public key of sender]
+encrypted with real private key of the sender, the nonce in the data packet and
+the real public key of the receiver:[[uint8_t id][data (optional)]]
+
+Data sent to us:
+announce response packet:
+[uint8_t packet id (132)][data to send back in response(fixed size)][nonce]
+encrypted with the DHT private key of Node D, the public key in the request and the nonce:[[uint8_t is_stored]
+[(32 bytes) ping_id if is_stored is 0 or 2, public key that must be used to send data packets if is_stored is 1][Node_Format * (maximum of 8)]]
+(if the is_stored is not 0, it means the information to reach the client id we are searching for is stored on this node)
+is_stored is 2 as a response to a peer trying to announce himself to tell the
+peer that he is currently announced successfully.
+
+data to route response packet:
+[uint8_t packet id (134)][nonce][temporary just generated public key]
+encrypted with that temporary private key, the nonce and the public key from the announce response packet of the destination node:[data]
+
+
+Onion packet (response):
+
+initial (sent from node D to node C):
+
+[uint8_t packet id (140)][nonce (for the following symmetric encryption)]encrypted with temp symmetric key of Node C:
+[IP_Port (of Node B)[nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node B:[IP_Port (of Node A)[nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node A: [IP_Port (of us)]]][data to send back]
+
+(sent from node C to node B):
+
+[uint8_t packet id (141)][nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node B:[IP_Port (of Node A)[nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node A: [IP_Port (of us)]][data to send back]
+
+(sent from node B to node A):
+
+[uint8_t packet id (142)][nonce (for the following symmetric encryption)]
+encrypted with temp symmetric key of Node A: [IP_Port (of us)][data to send back]
+
+(sent from node A to us):
+
+[data to send back]
+
+
+Data packets:
+
+To tell our friend what our DHT public key is so that he can connect to us we send a data packet 
+with id 156 and the data being:[uint64_t (in network byte order) no_replay, the packet will only be 
+accepted if this number is bigger than the last one received] [our dht public key][Node_Format * (
+maximum of 8) nodes closest to us so that the friend can find us faster]

data/ProjectTox-Core/docs/TCP_Network.txt

@@ -0,0 +1,154 @@
+It has come to our attention that to achieve decent market penetration Tox 
+must work behind ALL internet connections, may they be behind enterprise NATs 
+or any other bad network conditions. 
+
+The people who have issues with the UDP direct connection approach seem to be a 
+small minority though it is hard to estimate how many.
+
+This means that routing their packets using good nodes on the network will 
+probably not take a huge toll on the network and will assure that people
+can use Tox regardless of the quality of their internet connection.
+
+
+How it's going to work:
+1. Alice, a Tox client on a TCP only network generates a temporary public key 
+and connects to a bootstrap node.
+
+2. Using the bootstrap node she finds and connects to a couple (exact number 
+to be determined later) number of random nodes that have TCP relay support.
+
+3. She uses the onion through the TCP relay connections to send friend requests 
+or tell online friends which TCP nodes she is connected to and her temporary 
+public key.
+
+4. Bob receives an onion packet from Alice telling him which nodes she is 
+connected to. Bob connects to these nodes and establishes a routed connection 
+with alice using that temporary public key.
+
+5. That connection is used by both to transmit encrypted Messenger and A/V 
+packets.
+
+6. If one of the nodes shuts down while it is currently routing traffic, Alice 
+and bob just switch to one of the other nodes they are both connected to.
+
+
+Detailed implementation details:
+
+There are two distinct parts for TCP relays, the client part and the server 
+part.
+
+The server acts as the actual relay. Servers must have fully forwarded TCP 
+ports (NAT-PMP and uPNP can help here). The first port the server will try 
+binding to is 443 followed by port 3389 and possibly some others. Onion packets 
+can be sent/received through the TCP servers.
+
+
+Server:
+
+The public/private key pair the TCP server uses is the same one he uses for the 
+DHT. 
+
+all crypto for communication with the server uses the crypto_box() function of 
+NaCl.
+
+TCP doesn't have packets so what we will refer to as packets are sent this way: 
+[[uint16_t (length of data)][data]]
+
+So if you would inspect the TCP stream you would see:
+[[uint16_t (length of data)][data]][[uint16_t (length of 
+data)][data]][[uint16_t (length of data)][data]]
+
+Note that both handshake packets don't have this format (the length for them is 
+always the same so we don't need to specify it.)
+
+When the client connects to the server, he sends this packet:
+[public key of client (32 bytes)][nonce for the encrypted data [24 
+bytes]][encrypted with the private key of the client and public key of the 
+server and the nonce:[public key (32 bytes) and][base nonce we want the server 
+to use to encrypt the packets sent to us (24 bytes)]]
+
+The server responds with:
+[nonce for the encrypted data [24 bytes]][encrypted with the public key of the 
+client and private key of the server and the nonce:[public key (32 bytes) 
+and][base nonce we want the client to use to encrypt the packets sent to us (24 
+bytes)]]
+
+All packets to the server are end to end encrypted with the information 
+received 
+(and sent) in the handshake.
+
+(first packet is encrypted with the base nonce the private key for which the 
+client sent the server the public key and the public key we sent to the client, 
+the next with base nonce + 1...)
+
+The connection is set to an unconfirmed state until a packet is received and 
+decrypted correctly using the information in the handshake.
+
+each packet sent to/from the server has an id (the first byte of the plain text 
+data of the packet.)
+
+ids 0 to 15 are reserved for special packets, ids 16 to 255 are used to denote 
+who we want the data to be routed to/who the packet is from.
+
+special ids and packets:
+0 - Routing request.
+[uint8_t id (0)][public key (32 bytes)]
+1 - Routing request response.
+[uint8_t id (1)][uint8_t (rpid) 0 if refused, packet id if accepted][public key 
+(32 bytes)]
+2 - Connect notification:
+[uint8_t id (2)][uint8_t (packet id of connection that got connected)]
+3 - Disconnect notification:
+[uint8_t id (3)][uint8_t (packet id of connection that got disconnected)]
+4 - ping packet
+[uint8_t id (4)][uint64_t ping_id (0 is invalid)]
+5 - ping response (pong)
+[uint8_t id (5)][uint64_t ping_id (0 is invalid)]
+6 - OOB send
+[uint8_t id (6)][destination public key (32 bytes)][data]
+7 - OOB recv
+[uint8_t id (7)][senders public key (32 bytes)][data]
+8 - onion packet (same format as initial onion packet (See: Prevent 
+tracking.txt) but packet id is 8 instead of 128)
+9 - onion packet response (same format as onion packet with id 142 but id is 9 
+instead.)
+
+The rest of the special ids are reserved for possible future usage.
+
+If the server receives a routing request he stores server side that the client 
+wants to connect to the person with that public key and sends back a Routing 
+request response with the rpid along with the public key sent in the request.
+
+If for some reason the server must refuse the routing request (too many) he 
+sends the response with a rpid of 0.
+
+If the person who the client wants to connect to is also online and wants to 
+connect to the client a connect notification is sent to both with the 
+appropriate packet id.
+
+If either one disconnects, a disconnect notification is sent to the other with 
+appropriate packet id.
+
+If a client sends a disconnect notification, the entry on the server for that 
+routed connection is cleared and a disconnect notification is sent to the peer 
+(if he was online)
+
+If the server receives an onion packet he handles it the same as he would if it 
+was one received normally via UDP, he must also assure himself that any 
+responses must be sent to the proper client.
+
+Ping responses must have the same ping_id as the request.
+
+If the server receives a ping packet he must respond with a ping response.
+
+The server will send a ping packet to clients every 30 seconds, they have 30 
+seconds to respond, if they don't the connection is deleted.
+
+OOB send packets will be sent to the peer connected to the TCP server with the 
+destination public key as a OOB recv packet. The client sending this packet has 
+no way of knowing if the packet reached its destination.
+
+
+Client:
+
+Implementation details coming soon.