¿Cuáles son las implicaciones de las firmas de Schnorr?

Advertencia: nunca he trabajado con el esquema de firma de Schnorr. El siguiente es mi análisis basado en la lectura del artículo de Wikipedia , la página ed25519 y algunas discusiones entre desarrolladores en #bitcoin-dev .

Cambios probables

1. Se modificó el comportamiento del código de operación: necesitaremos un código de operación para verificar las firmas de Schnorr. Con una bifurcación dura, podemos redefinir op_checksigy op_checksigverifytambién verificar las firmas de Schnorr. Con una bifurcación suave, podemos redefinir uno de los códigos de operación sin operación reservados para verificar las firmas de Schnorr.

2. Mayor uso de P2SH (tal vez): creo que es muy poco probable que se introduzca un nuevo formato de dirección para hacer lo mismo con los scripts de clave pública que pagan las claves públicas de Schnorr que P2PKH hace con las claves públicas de ECDSA. Eso significa que las personas que quieran una dirección para usar Schnorr incluso con una sola clave (no multisig) tendrán que usar P2SH. Por supuesto, para las aplicaciones que no necesitan direcciones (como para minería o cuando se usa el protocolo de pago BIP70 ), pueden usar op_checksigverify_schnorr(o lo que sea) directamente en sus scripts de clave pública .

3. Transacciones multisig más pequeñas: una de las ventajas más promocionadas del esquema de Schnorr es que puede permitir que varios firmantes combinen sus firmas en una sola firma que se puede autenticar con una única clave pública creada por todas las partes autorizadas. Esto logra lo mismo que hace Bitcoin multisig actual, pero usa menos bytes. Esto puede ser especialmente útil si se requieren docenas o cientos de firmas, como en una situación de crowdfunding. Nota: si entiendo correctamente, esto también es posible con ECDSA, pero de una manera menos flexible. (Nota de 2018: ahora hay un documento que detalla cómo hacer scripts sin script en ECDSA , incluido 2-of-2 multisig)

4. Ligeramente más pequeño para todas las transacciones: asumiendo que Bitcoin usa la curva ed25519 , que tiene una fuerza de clave similar a la curva ECDSA secp256k1 que Bitcoin usa actualmente, las claves públicas y firmas comprimidas de Schnorr serán (respectivamente) de 32 bytes y hasta 64 bytes en comparación con la compresión actual. Claves públicas y firmas (no comprimidas) de Bitcoin secp256k1 de 33 bytes y hasta 75 bytes.

5. Denegación plausible para multisig: el uso de firmas de umbral de Schnorr puede ser más fácil para evitar que múltiples firmantes o terceros sepan quién más firmó o no firmó. Esto se debe a que las firmas individuales se fusionan en una firma unificada que no revela directamente quién la firmó. Esto se puede usar en situaciones en las que los firmantes temen represalias por gastar fondos de una manera particular.

6. Negación plausible de las partes autorizadasAl usar un organizador de terceros (que no necesita confiar en las claves privadas), es posible evitar que los firmantes sepan si su clave privada es parte del conjunto de claves de firma. Aunque no es directamente relevante para las transacciones de Bitcoin, creo recordar [1] que Greg Maxwell dijo que le gustaría ver esta propiedad utilizada para la moderación de foros distribuidos: elija un grupo de miembros del foro senior, obtenga una clave pública de cada uno de ellos, cree una clave pública de umbral de algunas de las claves públicas individuales, y luego permitir que las personas envíen una firma cuando crean que se debe eliminar una publicación. El organizador externo (probablemente un programa automatizado) combinará las firmas sin filtrar qué firma realmente contribuyó a alcanzar el umbral. Si nadie sabe de quién es la firma realmente importante y el grupo de posibles moderadores es grande, las represalias efectivas contra los moderadores se vuelven muy costosas. [1]: #bitcoin IRC hace unos 4 meses; desafortunadamente, esa sala de chat no está registrada públicamente.

7. Mejores propiedades de seguridad teóricas: los expertos están de acuerdo en que las firmas Schnorr generales tienen mejores propiedades de seguridad teóricas que las firmas ECDSA equivalentes. La más notable de estas mejoras es que la función hash utilizada en Schnorr no necesita ser tan resistente a colisiones como la función hash utilizada en ECDSA. (Bitcoin probablemente usaría la misma función hash para Schnorr que usa para ECDSA: SHA256). Además, la página ed25519 vinculada anteriormente describe varias formas en que es resistente a los ataques de canal lateral, lo que puede permitir que las billeteras de hardware operen de manera segura en entornos menos seguros. entornos.

8. Verificación de firma más rápida: es probable que se necesiten menos ciclos de CPU para verificar una firma Schnorr ed25519 que una firma ECDSA secp256k1. Esta es probablemente solo una pequeña mejora para Bitcoin: Bitcoin Core verifica las firmas antes de agregar una transacción a su mempool. Cuando se recibe un bloque que contiene transacciones que ya están en el mempol local, Bitcoin Core no vuelve a verificar esas transacciones, por lo que, siempre que el nodo local y el nodo de minería tengan mempools idénticos, no es necesario realizar verificaciones de firma. (Recuerde que la transacción de coinbase no tiene una firma). Sin embargo, la verificación de la firma es actualmente un factor límite para los nodos durante la descarga inicial de la cadena de bloques (suponiendo una conexión de alta velocidad y Bitcoin Core 0.10.0), por lo que "más rápido sería mejor". "

9. Multi-crypto multisig: con dos (ligeramente) diferentes criptosistemas para elegir, los usuarios de alta seguridad pueden crear 2 de 2 scripts de clave pública multisig que requieren firmas ECDSA y Schnorr, por lo que sus bitcoins no pueden ser robados si solo se utiliza un criptosistema. está roto. A menos que hagamos una bifurcación en Schnorr (consulte el punto n. ° 1), no podrán usar op_checkmultisig estándar, pero pueden hacer algo como<ecdsa pubkey> OP_CHECKSIGVERIFY <schnorr pubkey> OP_CHECKSIGVERIFY_SCHNORR

Incertidumbres (Para mí)

10. Tal vez TXID cambiados: no estoy lo suficientemente familiarizado con las firmas de Schnorr para saber cómo pueden ser maleables (cambiables por terceros sin invalidarlos), pero el experto en criptografía Adam Back parece pensar que serían bastante maleables. Su solución sería cambiar la forma en que se calculan los TXIDhash(<whole transaction>) de a hash(<almost everything except the signature>). Esto solucionaría algunos problemas actuales basados ​​en la maleabilidad , como la creación lenta de canales de micropagos , pero también sería una bifurcación importante que afectaría efectivamente a todo el software de Bitcoin. La última bifurcación de esa escala --- la implementación P2SH de bifurcación suave---todavía no cuenta con el apoyo de todos los programas de Bitcoin después de tres años de discusión, dos años de implementación y un uso bastante generalizado.

• Recuperación de clave pública de firmas: no sé si una clave pública de Schnorr se puede recuperar de una firma de Schnorr de la misma manera que se puede recuperar una clave pública ECDSA de una firma ECDSA. Esto podría ser importante: el verifymessageRPC de Bitcoin Core utiliza la recuperación de claves para verificar los mensajes firmados con el signmessageRPC o mediante la implementación de mensajes de firma de otro cliente. (Nota: este punto se dejó sin numerar porque se agregó después de la publicación original).

Sin cambios

Para que quede claro, aquí hay algunas cosas que no cambian.

11. Firmas deterministas: ha habido un impulso hacia las firmas ECDSA deterministas en el software de Bitcoin. Por ejemplo, Bitcoin Core comenzará a usarlos en la próxima versión 0.10.0. Las firmas de Schnorr también se pueden generar de forma determinista. Con las firmas deterministas, no necesita una fuente de entropía (aleatoriedad) de alta calidad para crear firmas seguras. Sin embargo, aún necesita entropía de alta calidad para generar claves privadas o semillas raíz (consulte el punto a continuación).

12. Carteras HD: me parece que el protocolo de generación de claves determinista jerárquico (HD) funcionará para los pares de claves Schnorr con algunas pequeñas modificaciones. Incluso puede usar la misma semilla raíz para las jerarquías ECDSA y Schnorr.

13. Reutilización de clave (dirección): al igual que con ECDSA correctamente implementado, es posible crear de forma segura múltiples firmas Schnorr para diferentes transacciones, lo que significa que es seguro recibir múltiples salidas en la misma dirección o clave pública. Esto contrasta con algunos esquemas de firma que solo le permiten usar de forma segura una firma por clave pública. Sin embargo, la reutilización de claves aún puede ser menos segura que el uso de claves únicas para cada transacción, y la reutilización de claves siempre será mucho menos privada para usted y sus socios comerciales.

Prioridad

Solo como una cuestión de mi opinión: Schnorr parece proporcionar algunas ventajas agradables sobre ECDSA para usuarios avanzados, pero nadie parece estar rogando por esas funciones, por lo que agregar firmas de Schnorr probablemente sea de baja prioridad. Supongo que el soporte de la firma de Schnorr podría ser una de las primeras mejoras que se probarán completamente en una cadena lateral (enlace PDF) antes de volver a transferirse a Bitcoin.

PD Perdón por la publicación larga, ¡pero gracias por hacer una pregunta tan divertida!

Sí, puede recuperar la clave pública con EC Schnorr. Considerar

R = kG, [r = R.x, s = k + H(r, m)d], Q = dG

verificar:

sG = ?R + H(r, m)Q

recuperación:

sG = kG + H(r, m) dG = R + H(r, m)Q

asi que

Q = 1 / H(r, m) * (sG - R).

(Y para calcular si está comprimido por puntos, Ry pruebe ambos y verifique si la firma es válida con la clave pública resultante).rRR = (r,f(r)) R' = (r,-f(r))RR'

El principal objetivo de diseño de DSA era evitar infringir la patente de Schnorr. Ahora que la patente ha expirado, realmente no hay buenas razones matemáticas para optar por DSA. Con Schnorr, el algoritmo y el análisis son más simples y, a menudo, más eficientes. También es más fácil dividir las claves privadas de Schnorr, crear variantes de umbral, etc. Sin embargo, DSA y ECDSA son estándares y lo han sido durante un tiempo. Como resultado, las implementaciones de bibliotecas están en todas partes. Puede encontrar compatibilidad con el módulo de seguridad de hardware, etc. Algún día, lo mismo ocurrirá con Ed25519 o alguna otra variante de Schnorr. Es poco probable que las personas estandaricen las nuevas variantes de DSA. Pero por el momento, ECDSA sigue siendo el algoritmo a utilizar si desea algo estándar y ampliamente compatible.