GingerWallet, la bifurcación de WasabiWallet mantenida por ex empleados de zkSNACKs después del cierre del coordinador de unión de monedas de Wasabi, recibió una informe de vulnerabilidad del desarrollador borracho. Esta vulnerabilidad permitiría la desanonimización total de las entradas y salidas de los usuarios en una ronda de coinjoin, dando a un coordinador malicioso la capacidad de deshacer por completo cualquier ganancia de privacidad derivada de la coinjoin mediante la realización de un ataque activo.
Wasabi 2.0 fue un rediseño completo de cómo Wasabi coordinó las combinaciones de monedas, pasando del marco Zerolink que utiliza cantidades mixtas de denominaciones fijas al protocolo Wabisabi que permite cantidades dinámicas de denominaciones múltiples. Este proceso implicó cambiar de tokens ciegos homogéneos para registrar salidas para reclamar sus monedas, a un sistema de credenciales dinámicas llamado Credenciales anónimas de verificación con clave (KVAC). Esto permitiría a los usuarios registrar cantidades ciegas que impidieran el robo de las monedas de otros usuarios sin revelar al servidor cantidades en texto plano que podrían correlacionarse y evitar vincular la propiedad de entradas separadas.
Cuando los usuarios comiencen a participar en una ronda, consulte al servidor coordinador para obtener información sobre la ronda. Esto devuelve un valor en los parámetros RoundCreated, llamado maxAmountCredentialValue. Esta es la credencial de mayor valor que emitirá el servidor. Cada emisión de credencial es identificable según el valor establecido aquí.
Para ahorrar ancho de banda, nunca se implementaron múltiples métodos propuestos para que los clientes verificaran cruzadamente esta información. Esto permite que un coordinador malicioso le dé a cada usuario, cuando comienza a registrar sus entradas, un maxAmountCredentialValue único. En mensajes posteriores al coordinador, incluido el registro de salida, el coordinador podría identificar con qué usuario se estaba comunicando en función de este valor.
Al «etiquetar» a cada usuario con un identificador único de esta manera, un coordinador malicioso puede ver qué salidas pertenecen a qué usuarios, anulando todos los beneficios de privacidad que podrían haber obtenido al unirse a una moneda.
Que yo sepa, drkgry descubrió esto de forma independiente y lo reveló de buena fe, pero los miembros del equipo que estuvieron presentes en zkSNACKs durante la fase de diseño de Wabisabi estaban absolutamente conscientes de este problema.
«El segundo propósito del hash redondo es proteger a los clientes de ataques de etiquetado por parte del servidor, los parámetros del emisor de credenciales deben ser idénticos para todas las credenciales y otros metadatos redondos deben ser los mismos para todos los clientes (por ejemplo, para garantizar que el servidor no sea el mismo). t tratar de influir en los clientes para crear algún sesgo detectable en los registros)”.
Fue criado en 2021 por Yuval Kogman, también conocido como Nothingmuch, en 2021. Yuval fue el desarrollador que diseñó lo que se convertiría en el protocolo Wabisabi, y uno de los diseñadores que en realidad especificó el protocolo completo con István András Seres.
Una nota final es que la vulnerabilidad del etiquetado no se aborda sin esta sugerencia de Yuval, así como pruebas de propiedad total vinculadas a UTXO reales como se propone en su solicitud de extraccion original discutiendo ataques de etiquetado. Todos los datos que se envían a los clientes no están vinculados a una ID de ronda específica, por lo que un coordinador malicioso aún es capaz de realizar un ataque similar al proporcionar a los usuarios ID de ronda únicas y simplemente copiar los datos necesarios y reasignar. cada identificación de ronda única. por usuario antes de enviar cualquier mensaje.
Esta no es la única vulnerabilidad sobresaliente presente en la implementación actual de Wasabi 2.0 creada por el resto del equipo tomando ataques durante la fase de implementación.