GingerWallet, o fork do WasabiWallet mantido por ex-funcionários do zkSNACKs após o encerramento do coordenador do Wasabi coinjoin, recebeu um relatório de vulnerabilidade do desenvolvedor drkgry. Essa vulnerabilidade permitiria a desanonimização total das entradas e saídas dos usuários em uma rodada de coinjoin, dando a um coordenador mal-intencionado a capacidade de desfazer completamente quaisquer ganhos de privacidade decorrentes do coinjoin, realizando um ataque ativo.
Wasabi 2.0 foi uma reformulação completa de como Wasabi coordenou coinjoins, passando da estrutura Zerolink utilizando quantidades mistas de denominação fixa, para o protocolo Wabisabi permitindo quantidades dinâmicas de múltiplas denominações. Esse processo envolveu a mudança de tokens cegos homogêneos para registrar saídas para reivindicar suas moedas de volta, para um sistema de credenciais dinâmico chamado Keyed Verification Anonymous Credentials (KVACs). Isso permitiria que os usuários registrassem valores ocultos que evitassem o roubo de moedas de outros usuários, sem revelar ao servidor valores em texto simples que poderiam ser correlacionados e evitariam vincular a propriedade de entradas separadas.
Quando os usuários começam a participar de uma rodada, eles consultam o servidor coordenador para obter informações sobre a rodada. Isso retorna um valor nos parâmetros RoundCreated, chamado maxAmountCredentialValue. Esta é a credencial de valor mais alto que o servidor emitirá. Cada emissão de credencial é identificável com base no valor aqui definido.
Para economizar largura de banda, vários métodos propostos para os clientes verificarem essas informações nunca foram implementados. Isso permite que um coordenador mal-intencionado forneça a cada usuário, quando ele começar a registrar suas entradas, um maxAmountCredentialValue exclusivo. Nas mensagens subsequentes ao coordenador, incluindo o registro de saída, o coordenador poderia identificar com qual usuário estava se comunicando com base neste valor.
Ao “marcar” cada usuário com um identificador exclusivo dessa forma, um coordenador mal-intencionado pode ver quais saídas pertencem a quais usuários, negando todos os benefícios de privacidade que poderiam ter obtido com a associação.
Que eu saiba, drkgry descobriu isso de forma independente e divulgou de boa fé, mas os membros da equipe que estiveram presentes no zkSNACKs durante a fase de design do Wabisabi estavam absolutamente cientes desse problema.
“O segundo objetivo do round hash é proteger os clientes de ataques de marcação do servidor, os parâmetros do emissor da credencial devem ser idênticos para todas as credenciais e outros metadados da rodada devem ser os mesmos para todos os clientes (por exemplo, para garantir que o servidor esteja ' (não estou tentando influenciar os clientes a criar algum preconceito detectável nos registros).”
Foi criado em 2021 por Yuval Kogman, também conhecido como nada, em 2021. Yuval foi o desenvolvedor que projetou o que se tornaria o protocolo Wabisabi, e um dos designers que realmente especificou o protocolo completo com István András Seres.
Uma observação final é que a vulnerabilidade de marcação não é realmente abordada sem esta sugestão de Yuval, bem como provas de propriedade total vinculadas a UTXOs reais, conforme proposto em sua solicitação pull original discutindo ataques de marcação. Todos os dados enviados aos clientes não estão vinculados a um ID de rodada específico, portanto, um coordenador mal-intencionado ainda é capaz de realizar um ataque semelhante, fornecendo aos usuários IDs de rodada exclusivos e simplesmente copiando os dados necessários e reatribuindo cada ID de rodada exclusivo. por usuário antes de enviar qualquer mensagem.
Esta não é a única vulnerabilidade pendente presente na implementação atual do Wasabi 2.0, criada pelo resto da equipe durante a fase de implementação.
Fonte: bitcoinmagazine.com
