Projet NLnet: Tor pour clients bas débit

Le système Tor anonymat est actuellement uniquement utilisable par les utilisateurs internet qui ont des connexions à haut débit. Dès lancement du client Tor, un grand fichier contenant toutes les descriptions de serveur Tor est téléchargé. Ce fichier, appellé le répertoire de Tor, permet au client de choisir parmi les serveurs de mélange disponibles dans le réseau Tor. Le téléchargement complet du répertoire Tor est requis par le protocole actuel de Tor. Ce répertoire fichier est trop volumineux pour les utilisateurs de modem sur des lignes ou des réseaux de données mobiles comme le GPRS car le téléchargement initial est déclenché à chaque fois qu'un utilisateur se connecte et prend de 10 à 30 minutes sur une ligne lente. En conséquence, Tor n'est pas utilisable par modem et par les utilisateurs mobiles. L'un des principaux objectifs du projet Tor est d'assurer la sécurité des accès anonymes à Internet pour les utilisateurs dans les dictatures et les états répressifs. Ces sites ont souvent de accès internet très lents, soit par modem ou en raison du bas débit des liens vers le monde extérieur. En permettant à ces utilisateurs d'utiliser le réseau Tor, des progrès significatifs peuvent être accomplis en vue de la liberté de communication et d'information dans ces pays.

Pour rendre Tor également utilisable pour les utilisateurs de connexions bas débit, une évolution du protocole Tor est nécessaire pour réduire la taille de téléchargement initial. Cette nouvelle version du protocole Tor devrait changer la façon dont un client reçoit les informations pour la création d'un circuit Tor de telle façon, que le téléchargement initial puisse être effectué à partir un ligne avec modem 14,4 kbps en trois minutes environ. Les travaux doivent mener de la proposition à la mise en production finale du protocole et à la diffusion auprès des utilisateurs dans un délai de moins de 12 mois. Le logiciel sera publiée sous la licence BSD 3, comme tout le code Tor. Tous les résultats seront entièrement publics.

Ce projet est généreusement financé par:

Projet	Date de livraison
Livrable A: Document de conception et évaluation du changement de protocole Ce livrable couvre la conception détaillée et la simulation fondée sur l'évaluation des changements nécessaires et la conception des modifications au protocole actuel de Tor. Les changements dans le protocole seront relativement important, de sorte qu'ils exigent une évaluation attentive des répercussions possibles pour la sécurité et l'anonymat du réseau Tor. Un délai de deux mois est prévu pour cette conception et d'évaluation, qui se termine par un vaste examen par les pairs. L'objectif d'une partie du livrable A sera la définition de la performance pour la phase de mise en œuvre. L'objectif de conception est de réduire la taille du répertoire Tor qui doit être téléchargé à environ 300 kilo-octets, ce qui permettrait à un utilisateur sur une ligne de 14,4 kbit/s pour le télécharger à peu près trois minutes. Il peut y avoir des exceptions à cet objectif de conception si nécessaire, afin de préserver l'anonymat et la sécurité, mais c'est la valeur à viser.	15 juillet 2008
Livrable B: Mise en œuvre du changement de protocole Après la conception, l'évaluation par les pairs et les modifications doivent être mises en œuvre et intégrées dans la version actuelle de code de Tor. La mise en œuvre effective des changements nécessaires prendra environ trois mois.	15 octobre 2008
Livrable C: Tests L'aspect très critique de la modification pour la sécurité et l'anonymat du réseau Tor, nécessite de nombreux essais et le débogage en laboratoire et en condtions d'utilisations réelles. Une période de trois mois est prévue pour tester et déboguer, où le développeur responsable passera 1/3 de son temps à des essais. Une partie de la phase d'essai sera une période de bêta publique.	15 novembre 2008
Livrable D: Déploiement Le déploiement dans le réseau des serveurs Tor sera réalisé en synchronisation avec le calendrier normal de diffusion de Tor. Comme ce calendrier dépend d'un certain nombre de facteurs externes, tel que l'achèvement d'autres projets de logiciels qui devraient aller dans le même livraison, la date de sortie effective et la date auquelle cette version a été accepté et installé par la plupart des opérateurs de serveur Tor peuvent varier. D'expérience une période de trois à quatre mois peut être prévue. Le déploiement sera effectué dans le cadre du processus de livraison Tor qui est une activité permanente fait par des bénévoles et du personnel payé par d'autres subventions du projet Tor.	15 Février 2009

Rapports mensuels d'avancement

Il y aura au total huit rapports mensuels de situation en commençant par le premier livrable le 15 juillet 2008 et terminant avec l'achèvement de la mise en oeuvre et les tests de bon fonctionnement le 15 février 2009.

Mois,	Rapport d'avancement
Jui 08	Nous n'avons fait une mesure initiale de vitesse des clients Tor. Les résultats ne sont pas très surprenants: un client récupère environ 10 Ko de certificats, un consensus pour 140KB (90KB maintenant, voir le paragraphe suivant), et environ 1,5 Mo de descripteurs de serveurs (et avec la moitié d'entre eux il commence la construction de circuits). La proposition 138 qui réduit de 30 à 40% les documents de consensus a déjà été réalisée et fusionnée en les spécifications. La mise en œuvre est en place dans la branche 0.2.1.x-alpha et le code prendra effet une fois de plus des deux-tiers des répertoires autorités (c'est-à-dire 5 sur 6) auront été mis à jour. Une proposition 140 qui ne se rapporte pas directement à la réduction de la taille du téléchargement initial, mais tente de rendre les nouveaux téléchargements de documents de consensus moins volumineux, a également été rédigée et envoyée à or-dev. Il y a des questions auxquelles doivent répondre les autres développeurs de Tor en premier, mais je pense que cela va bien et pourrait être mis en œuvre. Le Gros Travail est que les clients ne téléchargent pas tous les 1,5 Mo de descripteurs de serveurs. Une proposition 141 a été envoyée à or-dev. Il existe principalement 3 choses à l'intérieur, pour autant que je puisse voir actuellement: déplacer l'équilibrage des informations de charge dans le consensus (ne devrait pas être difficile), mettre en oeuvre quelque chose pour que clients Tor puissent récupérer les DSs à la demande de routeurs le long de leur circuit alors qu'ils sont en train de la construire (décrites dans le projet), et de selectionner le sortie. Nous sommes encore en phase de développement des idées pour cette dernière partie, plusieurs possibilités sont mentionnées dans le projet.
Juil 08	La travail sur la Proposition 141 continue: Il y a principalement deux idées sur la façon de déplacer les informations d'équilibrage de charge dans le consensus: la première est que les autorités générent le poids que les clients doivent utiliser et le mettre dans le consensus, l'autre approche est de mettre juste les informations de bande passante du descriteur du serveur. Cette dernière option est probablement plus pratique si l'on considère également la Proposition 140 qui évite d'avoir un nombre très fluctuant dans le consensus. Pour la gestion des politiques de sortie un message sur la liste or-dev propose qu'un hash identifie une politique de sortie ajoutée au document de consensus. L'addition de 160 bits aléatoires par noeud au consensus pourrait être un souci mais comme nous pensons qu'un grand nombre de politiques de sorties sont identiques, le document de consensus sera compressé efficacement. Des mesures sont en attente.
Aou 08
Sep 08
Oct 08
Nov 08
Déc 08
Jan 09