Len Sassaman fue un investigador de la privacidad que trabajó en sistemas de comunicación anónima. Contribuyó a los diseños de Mixmaster y Pynchon Gate, herramientas para reenviar y recuperar mensajes, estudiando sus debilidades y facilidad de uso además de sus posibilidades. Su trabajo pertenece a la historia de la privacidad digital; tener intereses de investigación similares no demuestra por sí solo que fuera Satoshi Nakamoto.
Imagine un servicio de correo privado cuya configuración casi nadie entiende. El diseño técnico puede ser ingenioso y, aun así, ayudar a pocas personas. Len Sassaman relacionaba privacidad y facilidad de uso: en su web de investigación explicaba que un sistema demasiado difícil puede no atraer a los usuarios que necesita. La comunicación anónima también depende del tráfico entre el que un mensaje puede confundirse. Por eso no preguntaba solo si funcionaban las matemáticas, sino si las personas podían utilizar correctamente el sistema. Estudiaba tanto su protección como las formas de vulnerarla. [1]
Una de esas vías era Mixmaster, un sistema de reenvío de correo que busca dificultar la asociación entre remitente y destinatario. Mixmaster Protocol Version 2, fechado el 29 de diciembre de 2004, enumera cuatro coautores: U. Moeller, L. Cottrell, P. Palfrader y L. Sassaman. Su aportación no necesita convertirse en una historia de inventor solitario. El documento es un Internet-Draft archivado, una propuesta de trabajo presentada en el ámbito del IETF, organización dedicada a los estándares de Internet. Figurar en ese archivo no lo convierte en un estándar aprobado por el IETF. Su valor aquí es dejar constancia precisa de lo propuesto. [2]
El contenido cifrado se parece a una carta en un sobre opaco: las palabras quedan ocultas, pero la entrega puede observarse. Esos datos del entorno se llaman metadatos: tamaño, horarios y frecuencia de los mensajes. El proyecto Mixmaster de 2004 combina capas de cifrado, paquetes de tamaño fijo y un depósito común desde el que los mensajes se reenvían gradualmente. Así intenta dificultar que una entrada se asocie a una salida concreta. Mezclar también implica esperar. Estos mecanismos explican cómo se construye la protección; no garantizan anonimato con cualquier forma de uso. [2]
Enviar una carta discretamente es solo una parte. Si alguien lo reconoce al vaciar el buzón, puede descubrir la relación desde el otro extremo. Len Sassaman, Bram Cohen y Nick Mathewson abordaron ese problema en The Pynchon Gate, de 2005. El diseño usa un canal anónimo existente para enviar. Para recibir emplea private information retrieval, o PIR: recuperar datos ocultando a los servidores qué elemento se busca. Envío y recuperación no son dos nombres de una misma operación. Protegen partes distintas del recorrido y ambas importan. [3]
El PIR del diseño de 2005 envía consultas diferentes a distribuidores seleccionados, servidores que proporcionan los datos almacenados. El artículo llama k a su número. El cliente combina las respuestas para recuperar el bloque deseado sin que una consulta individual anuncie directamente cuál busca. Esa protección supone que el atacante no controla todos los servidores elegidos. Por eso importa quién los opera. Varias direcciones controladas por una misma persona no equivalen a operadores independientes. El número de servidores no demuestra esa independencia; la condición debe corresponderse con el funcionamiento real. [3]
Imagine descargar muchos más datos solo cuando recibe mucho correo. Un observador puede aprender algo sin leer el contenido. Por eso el diseño de 2005 usa bloques de tamaño fijo y consultas adicionales hasta un máximo establecido. Para seguir esa protección, el cliente no puede detenerse siempre en cuanto recupera sus mensajes reales. El coste se entiende fácilmente: también transfiere datos que no harían falta para leer el correo. Aquí la privacidad depende del cifrado, del comportamiento del programa y de aceptar tráfico adicional. [3]
En el artículo de 2005, Pynchon Gate utiliza hashes, huellas digitales breves para comprobar datos, y un hash raíz común al conjunto organizado. Recalcular una huella ayuda a comprobar la coincidencia con los datos esperados. Pero si un atacante proporciona datos alterados y una raíz sustituida, coincidir con su propio valor no basta. Los autores requieren publicar ampliamente la información de verificación y comprobar que los distribuidores utilizados coinciden en la raíz. No solo importa si la huella coincide, sino de dónde procede la huella esperada. Verificar exige un punto de partida fiable. [3]
Además del artículo de Pynchon Gate, resulta útil leer el README, la presentación del proyecto de software. Su autor Nick Mathewson describe una implementación en desarrollo y enumera código de distribuidor y de agrupador, no un sistema completo. El agrupador prepara y organiza mensajes para distribuirlos; el software para el usuario es otro trabajo. Ese registro histórico no demuestra que el servicio esté listo para un uso seguro hoy. Eso no resta valor a Sassaman: ayudó a identificar problemas reales y a diseñar soluciones que se entienden mejor cuando también conocemos sus condiciones y límites. [4]
Para obtener la imagen más completa, lee esta entrada junto con Eric Hughes, Martti Malmi, Privacidad en Bitcoin. También enlazan con esta entrada Eric Hughes, Martti Malmi.