Len Sassaman était un chercheur en protection de la vie privée, spécialisé dans les communications anonymes. Il a contribué aux conceptions de Mixmaster et de Pynchon Gate, des outils de réexpédition et de récupération des messages. Il en étudiait les faiblesses et la facilité d’utilisation autant que les possibilités. Son travail appartient à l’histoire de la vie privée numérique ; des intérêts de recherche proches ne prouvent pas, à eux seuls, qu’il était Satoshi Nakamoto.
Imaginez un service de courrier privé que peu de personnes savent configurer. Sa conception technique peut être ingénieuse tout en aidant peu de monde en pratique. Len Sassaman reliait vie privée et facilité d’utilisation : sur son site de recherche, il expliquait qu’un système trop difficile risque de ne pas attirer les utilisateurs nécessaires. Une communication anonyme dépend aussi du trafic parmi lequel le message peut se fondre. Il ne demandait donc pas seulement si les mathématiques fonctionnaient, mais aussi si les gens pouvaient utiliser correctement le système. Il étudiait à la fois sa protection et les moyens de la mettre en défaut. [1]
Mixmaster était l’une de ces approches : un système de réexpédition de courriels destiné à compliquer le rapprochement entre expéditeur et destinataire. Mixmaster Protocol Version 2, daté du 29 décembre 2004, cite quatre coauteurs : U. Moeller, L. Cottrell, P. Palfrader et L. Sassaman. Nul besoin de transformer la contribution de Sassaman en récit d’inventeur solitaire. Le document est un Internet-Draft archivé, un projet de travail soumis dans le cadre de l’IETF, organisme consacré aux normes d’Internet. Sa présence dans ces archives n’en fait pas une norme IETF approuvée. Il constitue surtout une trace précise de ce que les auteurs proposaient. [2]
Un contenu chiffré ressemble à une lettre dans une enveloppe opaque : les mots restent cachés, mais la livraison est observable. Ces informations périphériques sont les métadonnées : taille des messages, horaires et fréquence des échanges. Dans le projet de 2004, Mixmaster associe plusieurs couches de chiffrement, des paquets de taille fixe et une réserve commune dont les messages repartent progressivement. Le but est de rendre plus difficile l’association d’une entrée à une sortie précise. Mélanger implique toutefois d’attendre. Ces mécanismes expliquent la construction de la protection, pas une garantie d’anonymat quel que soit l’usage. [2]
Envoyer discrètement une lettre ne règle qu’une partie du problème. Si quelqu’un vous reconnaît lorsque vous videz la boîte, le lien peut apparaître à l’autre extrémité. Len Sassaman, Bram Cohen et Nick Mathewson abordent cette difficulté dans The Pynchon Gate, publié en 2005. Pour l’envoi, le projet utilise un canal anonyme existant. Pour la réception, il emploie private information retrieval, ou PIR : récupérer des données en cachant aux serveurs l’élément recherché. Envoi et récupération ne sont donc pas deux noms d’une même opération. Ils protègent des parties différentes du trajet ; les deux comptent. [3]
Le PIR du projet de 2005 envoie des requêtes différentes à des distributeurs sélectionnés, des serveurs fournissant les données stockées. Leur nombre est noté k dans l’article. Le client combine leurs réponses pour retrouver le bloc voulu, sans qu’une requête individuelle annonce simplement lequel il cherche. Cette protection suppose que l’attaquant ne contrôle pas tous les serveurs choisis. L’identité des exploitants est donc importante. Plusieurs adresses contrôlées par la même personne ne valent pas des exploitants indépendants. Le nombre de serveurs ne prouve pas cette indépendance ; l’hypothèse doit correspondre au déploiement réel. [3]
Imaginez télécharger beaucoup plus de données uniquement lorsque vous recevez beaucoup de courrier. Un observateur peut en apprendre quelque chose sans lire le contenu. Le projet de 2005 prévoit donc des blocs de taille fixe et des requêtes supplémentaires jusqu’à un maximum défini. Pour suivre ce dispositif, le client ne doit pas toujours s’arrêter juste après avoir récupéré ses vrais messages. Le coût est simple à comprendre : il transfère aussi des données inutiles à la seule lecture du courrier. La vie privée dépend ici du chiffrement, mais aussi du comportement du logiciel et du trafic supplémentaire accepté. [3]
Dans l’article de 2005, Pynchon Gate utilise des hash, de courtes empreintes numériques servant à vérifier les données, ainsi qu’un hash racine commun à l’ensemble organisé. Recalculer une empreinte permet de vérifier la correspondance avec les données attendues. Mais si un attaquant fournit des données altérées et une racine substituée, la concordance avec sa propre valeur ne suffit pas. Les auteurs exigent donc une large publication des informations de vérification et le contrôle de l’accord des distributeurs utilisés sur la racine. Il faut savoir non seulement si l’empreinte correspond, mais aussi d’où vient la valeur attendue. La vérification exige un point de départ fiable. [3]
À côté de l’article sur Pynchon Gate, le README, texte d’introduction du projet logiciel, est instructif. Son auteur Nick Mathewson décrit une implémentation en cours et mentionne le code du distributeur et du collateur, pas un système complet. Le collateur prépare et organise les messages pour leur distribution ; le logiciel destiné aux utilisateurs est un autre chantier. Cet état historique ne prouve pas que le service soit prêt pour un usage sûr aujourd’hui. Cela ne diminue pas la contribution de Sassaman. Il a aidé à identifier des problèmes réels et à concevoir des solutions dont la valeur devient plus claire lorsqu’on comprend leurs conditions et leurs limites. [4]
Pour une vision complète, lisez aussi Eric Hughes, Martti Malmi, Confidentialité de Bitcoin. Cette entrée est également citée par Eric Hughes, Martti Malmi.