encontré algo casi por accidente esta noche, buceando en los issues de GitHub de Dusk en lugar de su documentación — un hilo de discusión sobre cómo Phoenix realmente deriva sus claves, y una falla reconocida en la forma en que se hace hoy.
Phoenix, como la mayoría de los protocolos protegidos, divide las claves en dos funciones:
una clave de gasto que puede mover fondos, y una clave de vista que solo puede verlos. Comparte la clave de vista con un contable o un auditor, y ellos ven tu actividad sin que nunca puedan tocarla. En teoría, es sencillo. Pero @Dusk los propios ingenieros de la fundación detectaron una debilidad real en la implementación actual: derivar una clave nueva actualmente requiere pasar la propia frase semilla completa, no algún valor intermedio derivado de ella. Esto rompe un principio básico de seguridad: el principio de menor privilegio, ya que cualquier código que gestione la derivación de claves termina manteniendo más material secreto del que realmente necesita.
Su solución, todavía en progreso: introducir una clave maestra separada entre la semilla y cada clave derivada, para que la semilla en bruto nunca tenga que viajar a través de la lógica de derivación. Un cambio arquitectónico pequeño, pero es la diferencia entre que un bug de billetera se mantenga contenido y que un bug de billetera exponga todo de una sola vez.
Lo que me impactó es que están haciendo este arreglo en público, a mitad de una migración, junto con una reestructuración estilo EIP-2333 para las claves de Moonlight también. La mayoría de las cadenas parchearían esto en silencio. Las billeteras aseguradas por $DUSK serán más seguras una vez que esto salga — pero, ¿debería una cadena centrada en la privacidad estar ejecutando esto expuesto durante el periodo de transición, o la iteración transparente es en realidad el camino más confiable? #dusk $DUSK @Dusk
Phoenix, como la mayoría de los protocolos protegidos, divide las claves en dos funciones:
una clave de gasto que puede mover fondos, y una clave de vista que solo puede verlos. Comparte la clave de vista con un contable o un auditor, y ellos ven tu actividad sin que nunca puedan tocarla. En teoría, es sencillo. Pero @Dusk los propios ingenieros de la fundación detectaron una debilidad real en la implementación actual: derivar una clave nueva actualmente requiere pasar la propia frase semilla completa, no algún valor intermedio derivado de ella. Esto rompe un principio básico de seguridad: el principio de menor privilegio, ya que cualquier código que gestione la derivación de claves termina manteniendo más material secreto del que realmente necesita.
Su solución, todavía en progreso: introducir una clave maestra separada entre la semilla y cada clave derivada, para que la semilla en bruto nunca tenga que viajar a través de la lógica de derivación. Un cambio arquitectónico pequeño, pero es la diferencia entre que un bug de billetera se mantenga contenido y que un bug de billetera exponga todo de una sola vez.
Lo que me impactó es que están haciendo este arreglo en público, a mitad de una migración, junto con una reestructuración estilo EIP-2333 para las claves de Moonlight también. La mayoría de las cadenas parchearían esto en silencio. Las billeteras aseguradas por $DUSK serán más seguras una vez que esto salga — pero, ¿debería una cadena centrada en la privacidad estar ejecutando esto expuesto durante el periodo de transición, o la iteración transparente es en realidad el camino más confiable? #dusk $DUSK @Dusk
