Zakura ha publicado una implementación experimental que otorga a las direcciones de swap de Zcash claves de visualización de entrada separadas, manteniendo la autoridad de gasto de la cuenta. Según su candidato de versión del 15 de octubre, la derivación de claves requiere revisión antes de emitir direcciones reales.

Una dirección de reembolso puede exponer más de un swap

Realizar swaps de ZEC a través de NEAR Intents requiere una dirección para devolver los fondos no utilizados. En una explicación de ingeniería, Adam Tucker de Zakura explica que esta dirección protegida de reembolso se registra en la blockchain pública de NEAR cuando se registra el depósito, incluso si nunca ocurre un reembolso. Los swaps hacia ZEC también publican la dirección receptora.

Estas direcciones pueden parecer no relacionadas mientras comparten una misma clave de visualización de entrada. Por lo tanto, recuperar esa clave podría revelar recibos más allá del propio swap.

El ataque descrito requeriría una computadora cuántica futura suficientemente capaz para recuperar la clave a partir de una dirección expuesta. Podría entonces identificar los pagos entrantes asociados a esa clave, incluidos montos y memos. La propuesta aborda ese riesgo de confidencialidad futuro, en lugar de reportar un ataque ya en curso. Y como esas direcciones quedan registradas en una blockchain pública, las exposiciones de hoy seguirían disponibles para ese tipo de análisis cuando llegue una máquina capaz, el patrón de exposición a largo plazo que la industria suele describir como harvest now, decrypt later.

Las claves de visualización separadas mantendrían intacta la cuenta de gasto

Zcash distingue la autoridad de visualización de la autoridad de gasto. Las claves de visualización están diseñadas para permitir a los titulares compartir acceso de solo lectura a sus pagos entrantes — para contabilidad o auditorías, por ejemplo — sin renunciar al control de los fondos. Su estándar de derivación de claves de wallet, descrito en ZIP 32, permite derivar claves y direcciones desde una única semilla, lo que permite a las wallets gestionar múltiples direcciones sin requerir un respaldo separado para cada una.

Simplemente generar otra dirección no crea necesariamente una clave de visualización de entrada independiente. El propuesto por Zakura opera detrás de la dirección: deriva una clave de visualización separada para cada reembolso de swap o swap entrante, según se describe en la documentación de la implementación.

La implementación preserva la autoridad de gasto de la cuenta. Un usuario podría gastar los fondos recibidos mediante esas claves de swap separadas desde la misma cuenta, evitando la carga operativa de dividir saldos entre muchas cuentas.

Bajo el modelo actual de clave compartida, recuperar una clave puede exponer pagos entrantes en varias direcciones. Con claves de swap separadas, recuperar la clave de visualización de un swap expondría los recibos vinculados a esa clave sin abrir automáticamente pagos entrantes no relacionados. Una clave de visualización no autoriza por sí misma el gasto. La protección prevista es más limitada: restringir el historial de pagos que una clave comprometida puede revelar.

La recuperación debe encontrar pagos sin revelar la propiedad

Las claves separadas crean un problema de descubrimiento al restaurar una wallet. Regenerar claves desde una semilla no indica a la wallet cuáles recibieron pagos. Probar cada clave de swap contra todo el historial de transacciones aumentaría el trabajo de recuperación con cada swap adicional.

Los swaps salientes ofrecen un lugar para dejar un registro de recuperación. La implementación propuesta coloca un memo cifrado en una nota perteneciente a la transacción de fondeo del usuario. Ese memo registra el índice usado para derivar la clave de reembolso. Durante la restauración, la wallet puede recuperar el índice y reconstruir la clave y dirección correspondientes.

Los swaps entrantes requieren otro enfoque, porque la wallet de Zcash no creó una transacción de fondeo donde dejar ese memo. En su lugar, el diseño verifica en secuencia direcciones derivadas de forma determinista, usando registros de direcciones pagadas o ya reveladas al proveedor del swap para determinar hasta dónde debe continuar el descubrimiento.

Para localizar pagos, el sistema de descubrimiento por receptor usa filtros públicos que la wallet verifica localmente. Una posible coincidencia genera una solicitud de recuperación privada de información, o PIR, que identifica la transacción relevante sin enviar al servidor una consulta legible que nombre la dirección.

La wallet puede entonces descifrar el pago con su clave de visualización correspondiente. Esto evita que cada clave recuperada realice una búsqueda separada en toda la cadena.

Las consultas privadas también impiden que una serie legible de solicitudes revele que varias direcciones pertenecen juntas. De lo contrario, un servidor podría recibir solicitudes para la dirección A, luego B, luego C y asociarlas con una sola wallet, socavando parte de la separación creada por las nuevas claves.

La revisión y el soporte de wallets siguen pendientes

El código experimental no establece que las wallets hayan habilitado la función para usuarios comunes. La revisión criptográfica sigue pendiente, y la implementación especifica que los firmantes de hardware necesitan certificación de firmware antes de habilitar las claves de un solo uso para cuentas de hardware.

La publicación de ingeniería de Zakura anticipa la integración en wallets de software compatibles, incluida Vizor, en las próximas semanas. Es una estimación de desarrollo, no una fecha de lanzamiento confirmada.

Este trabajo es independiente de las protecciones previstas para enero para pagos de Zcash, que se refieren a la autorización de pagos. La propuesta de swaps concierne a la privacidad del historial deos entrantes protegidos.

La nueva derivación tampoco puede eliminar direcciones ya registradas públicamente. Aislar las claves de swaps futuras no borraría exposiciones anteriores vinculadas a una clave de visualización compartida existente.

El trabajo restante es específico: revisar la derivación, integrar el descubrimiento de pagos y la restauración, y certificar los firmantes compatibles. Esos pasos deben completarse antes de que los usuarios puedan confiar en la separación propuesta en una wallet lanzada.

Este artículo se proporciona únicamente con fines informativos. La función propuesta es experimental y requiere revisión adicional antes de su uso real.

Este artículo apareció originalmente en Coindoo.