tor-webwml.git

1) 
2) 
3) 
4) 
5) 
6) 
7) ## translation metadata

8) # Revision: $Revision$

9) # Translation-Priority: 4-optional
10) #include "head.wmi" TITLE="Tor: Research" CHARSET="UTF-8"
11) <div class="main-column">
12) 
13) <h2>Tor : Recherche</h2>
14) <hr />
15) 
16) <p>
17) Plusieurs personnes dans le monde font de la recherche sur l'amélioration du
18) fonctionnement de Tor, sur ce qui se passe dans le réseau Tor et plus
19) généralement, sur les attaques et les modes de défense pour les systèmes de
20) communication anonymes. Cette page résume ce que nous fournissont pour
21) rendre votre recherche sur Tor plus efficace. Le meilleur moyen de nous
22) contacter sur le thème de la recherche est à travers la liste <a href="<page
23) contact>">tor-assistants</a>.
24) </p>
25) 
26) <ul>
27) 
28) <li>
29) <b>Données.</b> Nous avons <a
30) href="http://metrics.torproject.org/data.html">collecté des données pour en
31) apprendre davantage sur le réseau Tor</a>: combien de clients et de relais
32) sont dans le réseau, quelle est leur capacité, quelle est la vitesse du
33) réseau, la part de clients connectés par des passerelles, le traffic de
34) sortie du réseau, etc... Nous développons également des outils pour traiter
35) cette masse d'informations et pour réaliser <a
36) href="http://metrics.torproject.org/graphs.html">ces statistiques si
37) utiles<a>. Par exemple, nous fournissons <a
38) href="https://gitweb.torproject.org//ernie.git?a=blob_plain;f=doc/manual.pdf">un
39) outil appelé Ernie</a> qui peut importer les descripteurs de relais dans une
40) base de données locale à des fins d'analyse. Dîtes-nous quelles sont les
41) informations que vous voudriez observez et nous pourrons vous aider à les
42) collecter de <a
43) href="http://metrics.torproject.org/papers/wecsr10.pdf">manière
44) satisfaisante</a> et robuste.
45) </li>
46) 
47) <li>
48) <b>Analyse.</b> Si vous vous intéressez à Tor ou à résoudre un problème lié
49) à Tor, <i>_merci_</i> de nous en parler &mdash;le plus tôt étant le
50) mieux. En effet, nous rencontrons trop de sujets de conférence qui font de
51) mauvaises interprétations et qui concluent par la résolution du mauvais
52) problème. Étant donné que le protocole Tor et son réseau sont en mouvement
53) constant, faire des mesures sans comprendre ce qui se passe dérrière la
54) scène peut amener à formuler de mauvaises conclusions. Tout
55) particulièrement, certains groupes lancent involontairement tout un tas
56) d'expérimentations en parallèle alors qu'au même moment, nous modifions des
57) spécifications pour tenter de nouvelles approches. Si vous nous faîtes
58) savoir ce que vous êtes en train de faire et ce que vous tentez de
59) découvrir, nous pourrons vous aider à comprendre quels sont les autres
60) paramètres à retenir et comment interpréter vos résultats.
61) </li>
62) 
63) <li>
64) <b>Outils de mesures et d'attaques.</b> Nous sommes en train de mettre en
65) place un répértoire</a> d'outils qui peuvent être employés pour mesurer,
66) analyser ou effectuer des attaques sur Tor. De nombreux groupes de recherche
67) reconnaissent le besoin d'effectuer des mesures similaires (par exemple,
68) changer la conception de Tor et voir ensuite si la latence diminue), et nous
69) espérons pouvoir aider tout le monde en standardisant quelques outils et en
70) les rendant vraiment efficaces. De plus, alors que des attaques
71) intéréssantes de Tor ont été publiées, il est souvent difficile de récupérer
72) le code employé. Faîtes-nous savoir si vous avez de nouveaux outils que nous
73) devrions ajouter à cette liste ou si vous avez des améliorations pour ceux
74) qui existent actuellment. Plus il y en aura et mieux ce sera.
75) </li>
76) 
77) <li>
78) <b>Il nous faut des moyens de défenses également &mdash; pas seulement des
79) attaques.</b> La majorité des chercheurs sont intéressés par la mise au
80) point de nouvelles attaques sur les systèmes anonymes. Nous l'avons
81) récemment observé avec des attaques améliorées sur la congestion, des
82) attaques basées sur les mesures de latence ou de transfert,etc.... Savoir à
83) quel point les choses peuvent mal se comporter est important et nous
84) reconnaissons que les mesures d'incitation dans les universités ne sont pas
85) alignées sur l'effot de conception de moyens de défense. Mais il serait
86) vraiment bien d'accorder plus d'attention sur comment gérer ces
87) attaques. Nous aimerions "brainstormer" sur les moyens de rendre Tor plus
88) efficace. En bonus, votre publication devrait se terminer par une section
89) plus étoffée sur les "contre-mesures".
90) </li>
91) 
92) <li>
93) <b>Aide en personne.</b> Si vous menez un travail de recherche important et
94) intéressant sur Tor et que vous avez besoin de comprendre comment fonctionne
95) le réseau, d'interpréter vos données, de confronter vos expériences,
96) etc... nous pouvons vous envoyer un chercheur chez vous. Comme vous
97) l'imaginez, nous n'avons pas beaucoup de temps libre mais être sur que la
98) recherche est menée dans le sens utile est très important pour nous. Donc,
99) fâites-le nous savoir et nous travaillerons dessus.
100) </li>
101) 
102) </ul>
103) 
104) <a id="Groups"></a>
105) <h2><a class="anchor" href="#Groups">Groupes de recherche</a></h2>
106) 
107) <p>Vous désirez contacter d'autres chercheurs sur l'anonymat ? Voici quelques
108) groupes qui peuvent vous intéresser.</p>
109) 
110) <ul>
111) <li>Le groupe <a href="http://crysp.uwaterloo.ca/">CrySP</a> de Ian Goldberg
112) situé à Waterloo.
113) </li>
114) <li>Le groupe de <a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>
115) à UMN.
116) </li>
117) <li>Le groupe de <a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>
118) en Illinois.
119) </li>
120) <li>Le groupe <a href="http://isec.uta.edu/">iSec</a> de Matt Wright à UTA.
121) </li>
122) </ul>
123) 
124) <a id="Ideas"></a>
125) <h2><a class="anchor" href="#Ideas">Idées de recherche</a></h2>
126) 
127) <p>
128) Si vous êtes attirés par la recherche sur l'anonymat, vous devriez assister
129) au <a href="http://petsymposium.org/">Symposium des Technologies de
130) Renforcement de la Vie Privée (PETS)</a>. La crème de la recherche sur
131) l'anonymat y sera présente. La conférence 2010 aura lieu en juillet à
132) Berlin. Des remboursements sont possibles pour les personne dont la présence
133) profitera à la communauté.
134) </p>
135) 
136) <p>Pour être au fait de la recherche sur l'anonymat, lisez <a
137) href="http://freehaven.net/anonbib/">ces papiers</a> (notamment ceux dans
138) les cadres).</p>
139) 
140) <p>Nous avons besoin de personnes pour attaquer le système, évaluer ses
141) défenses, etc...  Voici quelques exemples de projets:</p>
142) 
143) <ul>
144) 

145) <li>If we prevent the really loud users from using too much of the Tor network,
146) how much can it help? We've instrumented Tor's entry relays so they can
147) rate-limit connections from users, and we've instrumented the directory
148) authorities so they can change the rate-limiting parameters globally across
149) the network. Which parameter values improve performance for the Tor network
150) as a whole? How should relays adapt their rate-limiting parameters based on
151) their capacity and based on the network load they see, and what
152) rate-limiting algorithms will work best? See the <a
153) href="https://blog.torproject.org/blog/research-problem-adaptive-throttling-tor-clients-entry-guards">blog
154) post</a> for details.
155) </li>
156) 
157) <li>Right now Tor clients are willing to reuse a given circuit for ten minutes
158) after it's first used. The goal is to avoid loading down the network with
159) too many circuit creations, yet to also avoid having clients use the same
160) circuit for so long that the exit node can build a useful pseudonymous
161) profile of them. Alas, ten minutes is probably way too long, especially if
162) connections from multiple protocols (e.g. IM and web browsing) are put on
163) the same circuit. If we keep fixed the overall number of circuit extends
164) that the network needs to do, are there more efficient and/or safer ways for
165) clients to allocate streams to circuits, or for clients to build preemptive
166) circuits? Perhaps this research item needs to start with gathering some
167) traces of what requests typical clients try to launch, so you have something
168) realistic to try to optimize.
169) </li>
170)