fr/research.wml (2d716acc1) - tor-webwml.git

research.wml

## translation metadata
# Revision: $Revision$
# Translation-Priority: 4-optional
#include "head.wmi" TITLE="Tor: Research" CHARSET="UTF-8"
<div class="main-column">

<h2>Tor : Recherche</h2>
<hr />

<p>
Plusieurs personnes dans le monde font de la recherche sur l'amélioration du
fonctionnement de Tor, sur ce qui se passe dans le réseau Tor et plus
généralement, sur les attaques et les modes de défense pour les systèmes de
communication anonymes. Cette page résume ce que nous fournissont pour
rendre votre recherche sur Tor plus efficace. Le meilleur moyen de nous
contacter sur le thème de la recherche est à travers la liste <a href="<page
contact>">tor-assistants</a>.
</p>

<ul>

<li>
<b>Données.</b> Nous avons <a
href="http://metrics.torproject.org/data.html">collecté des données pour en
apprendre davantage sur le réseau Tor</a>: combien de clients et de relais
sont dans le réseau, quelle est leur capacité, quelle est la vitesse du
réseau, la part de clients connectés par des passerelles, le traffic de
sortie du réseau, etc... Nous développons également des outils pour traiter
cette masse d'informations et pour réaliser <a
href="http://metrics.torproject.org/graphs.html">ces statistiques si
utiles<a>. Par exemple, nous fournissons <a
href="https://gitweb.torproject.org//ernie.git?a=blob_plain;f=doc/manual.pdf">un
outil appelé Ernie</a> qui peut importer les descripteurs de relais dans une
base de données locale à des fins d'analyse. Dîtes-nous quelles sont les
informations que vous voudriez observez et nous pourrons vous aider à les
collecter de <a
href="http://metrics.torproject.org/papers/wecsr10.pdf">manière
satisfaisante</a> et robuste.
</li>

<li>
<b>Analyse.</b> Si vous vous intéressez à Tor ou à résoudre un problème lié
à Tor, <i>_merci_</i> de nous en parler &mdash;le plus tôt étant le
mieux. En effet, nous rencontrons trop de sujets de conférence qui font de
mauvaises interprétations et qui concluent par la résolution du mauvais
problème. Étant donné que le protocole Tor et son réseau sont en mouvement
constant, faire des mesures sans comprendre ce qui se passe dérrière la
scène peut amener à formuler de mauvaises conclusions. Tout
particulièrement, certains groupes lancent involontairement tout un tas
d'expérimentations en parallèle alors qu'au même moment, nous modifions des
spécifications pour tenter de nouvelles approches. Si vous nous faîtes
savoir ce que vous êtes en train de faire et ce que vous tentez de
découvrir, nous pourrons vous aider à comprendre quels sont les autres
paramètres à retenir et comment interpréter vos résultats.
</li>

<li>
<b>Outils de mesures et d'attaques.</b> Nous sommes en train de mettre en
place un répértoire</a> d'outils qui peuvent être employés pour mesurer,
analyser ou effectuer des attaques sur Tor. De nombreux groupes de recherche
reconnaissent le besoin d'effectuer des mesures similaires (par exemple,
changer la conception de Tor et voir ensuite si la latence diminue), et nous
espérons pouvoir aider tout le monde en standardisant quelques outils et en
les rendant vraiment efficaces. De plus, alors que des attaques
intéréssantes de Tor ont été publiées, il est souvent difficile de récupérer
le code employé. Faîtes-nous savoir si vous avez de nouveaux outils que nous
devrions ajouter à cette liste ou si vous avez des améliorations pour ceux
qui existent actuellment. Plus il y en aura et mieux ce sera.
</li>

<li>
<b>Il nous faut des moyens de défenses également &mdash; pas seulement des
attaques.</b> La majorité des chercheurs sont intéressés par la mise au
point de nouvelles attaques sur les systèmes anonymes. Nous l'avons
récemment observé avec des attaques améliorées sur la congestion, des
attaques basées sur les mesures de latence ou de transfert,etc.... Savoir à
quel point les choses peuvent mal se comporter est important et nous
reconnaissons que les mesures d'incitation dans les universités ne sont pas
alignées sur l'effot de conception de moyens de défense. Mais il serait
vraiment bien d'accorder plus d'attention sur comment gérer ces
attaques. Nous aimerions "brainstormer" sur les moyens de rendre Tor plus
efficace. En bonus, votre publication devrait se terminer par une section
plus étoffée sur les "contre-mesures".
</li>

<li>
<b>Aide en personne.</b> Si vous menez un travail de recherche important et
intéressant sur Tor et que vous avez besoin de comprendre comment fonctionne
le réseau, d'interpréter vos données, de confronter vos expériences,
etc... nous pouvons vous envoyer un chercheur chez vous. Comme vous
l'imaginez, nous n'avons pas beaucoup de temps libre mais être sur que la
recherche est menée dans le sens utile est très important pour nous. Donc,
fâites-le nous savoir et nous travaillerons dessus.
</li>

</ul>

<a id="Groups"></a>
<h2><a class="anchor" href="#Groups">Groupes de recherche</a></h2>

<p>Vous désirez contacter d'autres chercheurs sur l'anonymat ? Voici quelques
groupes qui peuvent vous intéresser.</p>

<ul>
<li>Le groupe <a href="http://crysp.uwaterloo.ca/">CrySP</a> de Ian Goldberg
situé à Waterloo.
</li>
<li>Le groupe de <a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>
à UMN.
</li>
<li>Le groupe de <a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>
en Illinois.
</li>
<li>Le groupe <a href="http://isec.uta.edu/">iSec</a> de Matt Wright à UTA.
</li>
</ul>

<a id="Ideas"></a>
<h2><a class="anchor" href="#Ideas">Idées de recherche</a></h2>

<p>
Si vous êtes attirés par la recherche sur l'anonymat, vous devriez assister
au <a href="http://petsymposium.org/">Symposium des Technologies de
Renforcement de la Vie Privée (PETS)</a>. La crème de la recherche sur
l'anonymat y sera présente. La conférence 2010 aura lieu en juillet à
Berlin. Des remboursements sont possibles pour les personne dont la présence
profitera à la communauté.
</p>

<p>Pour être au fait de la recherche sur l'anonymat, lisez <a
href="http://freehaven.net/anonbib/">ces papiers</a> (notamment ceux dans
les cadres).</p>

<p>Nous avons besoin de personnes pour attaquer le système, évaluer ses
défenses, etc...  Voici quelques exemples de projets:</p>

<ul>

<li>If we prevent the really loud users from using too much of the Tor network,
how much can it help? We've instrumented Tor's entry relays so they can
rate-limit connections from users, and we've instrumented the directory
authorities so they can change the rate-limiting parameters globally across
the network. Which parameter values improve performance for the Tor network
as a whole? How should relays adapt their rate-limiting parameters based on
their capacity and based on the network load they see, and what
rate-limiting algorithms will work best? See the <a
href="https://blog.torproject.org/blog/research-problem-adaptive-throttling-tor-clients-entry-guards">blog
post</a> for details.
</li>

<li>Right now Tor clients are willing to reuse a given circuit for ten minutes
after it's first used. The goal is to avoid loading down the network with
too many circuit creations, yet to also avoid having clients use the same
circuit for so long that the exit node can build a useful pseudonymous
profile of them. Alas, ten minutes is probably way too long, especially if
connections from multiple protocols (e.g. IM and web browsing) are put on
the same circuit. If we keep fixed the overall number of circuit extends
that the network needs to do, are there more efficient and/or safer ways for
clients to allocate streams to circuits, or for clients to build preemptive
circuits? Perhaps this research item needs to start with gathering some
traces of what requests typical clients try to launch, so you have something
realistic to try to optimize.
</li>

<li>L'attaque par "empreinte de sites web": prenez une liste d'une centaine de
sites web populaires, téléchargez leurs pages et créez des jeux de
"signature" pour chacun d'entre eux. Observez alors le traffic d'un client
Tor. Alors que vous l'observez en train de recevoir, vous pouvez quasiment
deviner lequel de ces sites il est en train de visiter. Quelle est
l'efficacité de cette attaque sur le réseau actuellement déployé ?
L'inconvénient de toutes les publications antérieures est qu'elles observent
le timing et le décompte des paquets IP. Mais les enregistrements OpenSSL et
le fait que Tor utilise le pushback TCP pour limiter la charge font que
tracer les paquets donne de maigres résultats. La bonne approche est de se
rendre compte que Tor utilise OpenSSL, d'observer les enregistrements TLS et
leurs en-têtes et de déterminer combien de cellules de 512 octets ont été
reçues ou envoyées. En guise de parade, nous pourrions changer la taille des
cellules Tor de 512 à 1024 octets ou utiliser des techniques de gonflement
des en-têtes comme le <a
href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a> ou
encore introduire des délais dans le traffic. Quels impacts peuvent avoir
ces parades et quels peuvent être leurs impacts ?</li>

<!--
<li>

Path selection algorithms, directory fetching schedules for Tor-on-mobile
that are compatible anonymity-wise with our current approaches.
</li>

-->
<li>D'autres sujets bientôt. Consultez également la section « Recherche » de la
page <a href="<page volunteer>#Research">Contribuer</a>.
</li>

</ul>

</div>

#include <foot.wmi>

tor-webwml.git

new, updated, removed files for the website