Tuve una conversación esta semana sobre cómo Phoenix logra la desvinculabilidad específicamente cómo la misma nota puede dirigirse a alguien sin revelar quién es esa persona. El mecanismo del whitepaper es una sola fórmula que hace dos cosas distintas según quién la esté leyendo.
La fórmula es la clave pública de la nota: npk = H(rA)G + B. El remitente la calcula usando la clave pública del destinatario (A, B) y un valor aleatorio r que elige fresco para cada transacción. R = rG se incluye en la nota y es pública. Pero r en sí es secreta y se descarta después de usarse.
Lo que npk hace para el remitente: como r es aleatoria y fresca cada vez, la clave pública de la nota cambia en cada transacción. Aunque el remitente envíe diez notas al mismo destinatario, cada nota tiene un npk diferente. Ningún observador que mire la cadena puede vincular varias notas entre sí ni con la identidad del remitente basándose solo en los datos públicos.
Lo que NPK hace para el destinatario: solo el destinatario puede identificar cuáles notas son suyas. Toman su clave de visualización (a B) y comprueban si npk es igual a H(aR)G + B para cualquier nota con la que se encuentren. Esa comprobación funciona porque las matemáticas rA y aR producen el mismo valor cuando A = aG. Por lo tanto, la clave de visualización del destinatario es suficiente para escanear notas entrantes.
Mismo objetivo. Mecanismo fundamentalmente diferente para cada parte. La aleatoriedad del remitente oculta quién envió qué. El material de claves del destinatario hace que ellos sean la única parte que puede identificar lo que les corresponde. El gasto requiere la clave secreta completa (a b) para calcular la clave secreta de la nota nsk = H(aR) + b, así que la clave de visualización da visibilidad sin capacidad de gasto.
#dusk
En realidad, encuentro que la interacción entre estos dos usos de la misma fórmula es más elegante que cualquier parte individual: tanto el remitente como el destinatario están protegidos de cosas diferentes por la misma pieza de criptografía.
Lo que no he resuelto es si la elección de r afecta algo más allá de la desvinculabilidad; si una r débil o predecible tendría implicaciones de seguridad más allá de permitir la vinculación de transacciones; o si el único ataque de una r débil es.
@Dusk
$DUSK
La fórmula es la clave pública de la nota: npk = H(rA)G + B. El remitente la calcula usando la clave pública del destinatario (A, B) y un valor aleatorio r que elige fresco para cada transacción. R = rG se incluye en la nota y es pública. Pero r en sí es secreta y se descarta después de usarse.
Lo que npk hace para el remitente: como r es aleatoria y fresca cada vez, la clave pública de la nota cambia en cada transacción. Aunque el remitente envíe diez notas al mismo destinatario, cada nota tiene un npk diferente. Ningún observador que mire la cadena puede vincular varias notas entre sí ni con la identidad del remitente basándose solo en los datos públicos.
Lo que NPK hace para el destinatario: solo el destinatario puede identificar cuáles notas son suyas. Toman su clave de visualización (a B) y comprueban si npk es igual a H(aR)G + B para cualquier nota con la que se encuentren. Esa comprobación funciona porque las matemáticas rA y aR producen el mismo valor cuando A = aG. Por lo tanto, la clave de visualización del destinatario es suficiente para escanear notas entrantes.
Mismo objetivo. Mecanismo fundamentalmente diferente para cada parte. La aleatoriedad del remitente oculta quién envió qué. El material de claves del destinatario hace que ellos sean la única parte que puede identificar lo que les corresponde. El gasto requiere la clave secreta completa (a b) para calcular la clave secreta de la nota nsk = H(aR) + b, así que la clave de visualización da visibilidad sin capacidad de gasto.
#dusk
En realidad, encuentro que la interacción entre estos dos usos de la misma fórmula es más elegante que cualquier parte individual: tanto el remitente como el destinatario están protegidos de cosas diferentes por la misma pieza de criptografía.
Lo que no he resuelto es si la elección de r afecta algo más allá de la desvinculabilidad; si una r débil o predecible tendría implicaciones de seguridad más allá de permitir la vinculación de transacciones; o si el único ataque de una r débil es.
@Dusk
$DUSK
