Len Sassaman foi um pesquisador de privacidade que trabalhou em sistemas de comunicação anônima. Contribuiu para os projetos Mixmaster e Pynchon Gate, ferramentas de reencaminhamento e recuperação de mensagens. Estudava suas fraquezas e facilidade de uso, além de suas possibilidades. O seu trabalho integra a história da privacidade digital; interesses de pesquisa semelhantes não provam, por si sós, que fosse Satoshi Nakamoto.
Imagine um serviço de correio privado cuja configuração poucas pessoas entendem. O projeto técnico pode ser engenhoso e ainda assim ajudar pouca gente. Len Sassaman ligava privacidade à facilidade de uso: no seu site de pesquisa, explicava que um sistema difícil demais pode não atrair os usuários necessários. A comunicação anônima também depende do tráfego no qual uma mensagem pode se misturar. A pergunta não era apenas se a matemática funcionava, mas se as pessoas conseguiriam usar corretamente o sistema. Ele estudava tanto a proteção quanto as maneiras de quebrá-la. [1]
Uma dessas abordagens era o Mixmaster, um sistema de reencaminhamento de e-mails destinado a dificultar a ligação entre remetente e destinatário. Mixmaster Protocol Version 2, de 29 de dezembro de 2004, lista quatro coautores: U. Moeller, L. Cottrell, P. Palfrader e L. Sassaman. A contribuição de Sassaman não precisa virar uma história de inventor solitário. O documento é um Internet-Draft arquivado, uma proposta de trabalho apresentada no âmbito do IETF, organização dedicada a padrões da Internet. Estar nesse arquivo não o torna um padrão aprovado pelo IETF. O seu valor aqui é registrar concretamente o que os autores propunham. [2]
O conteúdo cifrado lembra uma carta num envelope opaco: as palavras ficam escondidas, mas a entrega pode ser observada. Esses dados ao redor da comunicação são os metadados: tamanho, horários e frequência das mensagens. O projeto Mixmaster de 2004 combina camadas de criptografia, pacotes de tamanho fixo e um conjunto comum do qual as mensagens saem gradualmente. A intenção é dificultar a associação de uma entrada a uma saída específica. Misturar também significa esperar. Esses mecanismos explicam como a proteção é construída, sem prometer anonimato independentemente da forma de uso. [2]
Enviar uma carta discretamente resolve apenas parte do problema. Se alguém reconhece você ao esvaziar a caixa postal, pode revelar a ligação pela outra ponta. Len Sassaman, Bram Cohen e Nick Mathewson trataram disso no artigo The Pynchon Gate, de 2005. Para enviar, o projeto usa um canal anônimo existente. Para receber, usa private information retrieval, ou PIR: recuperar dados ocultando dos servidores qual item está sendo procurado. Envio e recuperação não são dois nomes da mesma operação. Protegem partes diferentes do percurso, e ambas importam. [3]
O PIR do projeto de 2005 envia consultas diferentes a distribuidores selecionados, servidores que fornecem os dados armazenados. O artigo chama seu número de k. O cliente combina as respostas para obter o bloco desejado sem que uma consulta individual anuncie diretamente qual procura. Essa proteção pressupõe que o atacante não controla todos os servidores escolhidos. Por isso importa quem os opera. Vários endereços controlados pela mesma pessoa não equivalem a operadores independentes. A quantidade de servidores não demonstra essa independência; a condição precisa corresponder à operação real. [3]
Imagine baixar muito mais dados apenas quando recebe muita correspondência. Um observador pode aprender algo sem ler o conteúdo. O projeto de 2005 usa, portanto, blocos de tamanho fixo e consultas adicionais até um máximo definido. Para cumprir essa proteção, o cliente não pode sempre parar assim que obtém suas mensagens reais. O custo é fácil de entender: transfere também dados desnecessários para simplesmente ler o correio. A privacidade resulta da criptografia, do comportamento do programa e da disposição de aceitar tráfego adicional. [3]
No artigo de 2005, Pynchon Gate usa hashes, pequenas impressões digitais para verificar dados, e um hash raiz comum ao conjunto organizado. Recalcular a impressão ajuda a conferir a correspondência com os dados esperados. Mas, se o atacante fornece dados alterados e uma raiz substituída, coincidir com o valor dele não basta. Os autores exigem ampla publicação das informações de verificação e a conferência de que os distribuidores utilizados concordam sobre a raiz. Não importa apenas se a impressão coincide, mas de onde sabemos qual deveria ser. Verificar exige um ponto de partida confiável. [3]
Além do artigo sobre Pynchon Gate, vale ler o README, a introdução do projeto de software. O autor Nick Mathewson descreve uma implementação em andamento e lista código do distribuidor e do agregador, não um sistema completo. O agregador prepara e organiza as mensagens para distribuição; o programa destinado ao usuário é outro trabalho. Esse registro histórico não comprova que o serviço esteja pronto para uso seguro hoje. Isso não reduz a contribuição de Sassaman: ele ajudou a identificar problemas reais e a propor soluções que entendemos melhor quando conhecemos suas condições e limites. [4]
Para ter uma visão mais completa, leia este verbete junto com Eric Hughes, Martti Malmi, Privacidade no Bitcoin. Também há referências a este verbete em Eric Hughes, Martti Malmi.