Las claves públicas y privadas son un aspecto importante de la mayoría de las criptomonedas y un componente esencial que permite la existencia de blockchains como Polkadot.

Claves de Cuenta #

Las claves de cuenta son claves que sirven para controlar los fondos. Pueden ser de dos tipos:

• La implementación vanilla ed25519 que utiliza firmas Schnorr.
• La variante Schnorrkel/Ristretto sr25519 usando firmas Schnorr.
• Firmas ECDSA en secp256k1

No hay diferencias de seguridad entre ed25519 y sr25519 para las firmas simples.

Esperamos que ed25519 sea mucho más compatible con los HSM comerciales en un futuro predecible.

Al mismo tiempo, sr25519 hace más segura la implementación de protocolos más complejos. En particular, sr25519 viene con una versión más segura de muchos protocolos como el HDKD común en el ecosistema de Bitcoin y Ethereum.

Claves “Controller” y “Stash” #

Cuando hablamos de claves de “controller” y “stash”, solemos hablar de ellas en el contexto de la ejecución de un validador o de un DOT nominador, pero son conceptos útiles que todos los usuarios deben conocer. Ambas claves son tipos de claves de cuenta. Se distinguen por su uso previsto, no por una diferencia criptográfica subyacente. Toda la información mencionada en la sección principal se aplica a estas claves. Al crear nuevas claves de controller o de stash, toda la criptografía soportada por las claves de cuenta es una opción disponible.

La clave de controller es una clave semi-online que estará bajo el control directo de un usuario, y que se utilizará para presentar extrínsecos manuales. Para los validadores o nominadores, esto significa que la clave de controller se utilizará para iniciar o detener la validación o nominación. Las claves controller (controladoras) deben contener algún DOT para pagar las tarifas, pero no deben utilizarse para guardar grandes cantidades o los ahorros de toda la vida. Dado que estarán expuestas a Internet con relativa frecuencia, deben tratarse con cuidado y sustituirse de vez en cuando por otras nuevas.

La clave de stash es una clave que, en la mayoría de los casos, será una wallet o billetera fría, que existirá en un trozo de papel en una caja fuerte o estará protegido por capas de seguridad de hardware. Rara vez, o nunca, debería estar expuesta a Internet o utilizarse para enviar extrínsecos. La clave de stash está pensada para guardar una gran cantidad de fondos. Hay que pensar en ella como en una cuenta de ahorros en un banco, que idealmente sólo se toca en condiciones de urgencia. O, tal vez, una metáfora más adecuada es pensar en ella como un tesoro enterrado, escondido en alguna isla al azar y sólo conocido por el pirata que lo escondió originalmente.

Dado que la clave de stash se mantiene fuera de línea, debe configurarse para que sus fondos estén vinculados a un controller concreto. Para las acciones que no son de gasto, el controller tiene los fondos del stash detrás de él. Por ejemplo, al nominar, hacer staking o votar, el controller puede indicar su preferencia con el peso del stash. Nunca podrá mover o reclamar los fondos de la clave del stash. Sin embargo, si alguien obtiene tu clave de controller, podría utilizarla para un comportamiento slashable, por lo que deberías protegerla y cambiarla regularmente.

Claves de Sesión #

Las claves de sesión son claves calientes que deben ser mantenidas en línea por un validador para realizar operaciones de red. Las claves de sesión suelen generarse en el cliente, aunque no tienen por qué hacerlo. No están pensadas para controlar los fondos y sólo deben utilizarse para su propósito. Pueden cambiarse regularmente; tu controller sólo necesita crear un certificado firmando una clave pública de sesión y difundir este certificado a través de un extrínseco.

Polkadot utiliza cuatro claves de sesión:

• GRANDA: ed25519
• BABE: sr25519
• I’m Online: sr25519
• Parachain: sr25519

BABE requiere claves adecuadas para su uso en una Función Aleatoria Verificable, así como para las firmas digitales. Las claves sr25519 tienen ambas capacidades y por eso se utilizan para BABE.

En el futuro, tenemos previsto utilizar una clave BLS para GRANDPA porque permite una agregación de firmas más eficiente.

Preguntas Frecuentes #

¿Por qué se eligió ed25519 en lugar de secp256k1? #

La criptografía original de derivación de claves que se implementó para las cadenas Polkadot y Substrate fue ed25519, que es un algoritmo de firma Schnorr implementado sobre la Curva de Edward 25519 (llamada así por los parámetros de la ecuación de la curva).

La mayoría de las criptomonedas, incluidas Bitcoin y Ethereum, utilizan actualmente firmas ECDSA sobre la curva secp256k1. Esta curva se considera mucho más segura que las curvas NIST, que tienen posibles puertas traseras de la NSA (ver infra). La curva25519 se considera posiblemente aún más segura que ésta y permite una implementación más fácil de las firmas Schnorr. La reciente expiración de la patente sobre ella ha hecho que sea la opción preferida para su uso en Polkadot.

La elección de utilizar firmas Schnorr en lugar de ECDSA no es tan sencilla. Como se indica en el mensaje original del foro de Jeff Burdges (un investigador de Web3) sobre el tema:

• Hay un sacrificio que hacemos al elegir las firmas Schnorr sobre las firmas ECDSA para las claves de cuentas: Ambas requieren 64 bytes, pero sólo las firmas ECDSA comunican su clave pública. Hay variantes obsoletas de Schnorr que permiten recuperar la clave pública de una firma, pero rompen funcionalidades importantes como la derivación jerárquica determinista de claves. En consecuencia, las firmas Schnorr a menudo toman 32 bytes adicionales para la clave pública”.

Pero, en última instancia, las ventajas de utilizar las firmas Schnorr superan las desventajas, y las futuras optimizaciones pueden resolver las ineficiencias señaladas en la cita anterior.

¿Qué es sr25519 y de dónde viene? #

Un poco de contexto: Las firmas Schnorr sobre la Twisted Edward’s Curve25519 se consideran seguras, sin embargo Ed25519 no ha estado completamente exento de sus errores. En particular, Monero y todas las demás monedas CryptoNote eran vulnerables a un exploit de doble gasto que podría haber llevado a una inflación infinita no detectada.

Estos exploits se debían a una peculiaridad en la Ed25519, que se conoce como su cofactor de 8. El cofactor de una curva es un detalle esotérico que podría tener consecuencias nefastas para la seguridad de la implementación de protocolos más complejos.

Convenientemente, el documento Decaf de Mike Hamburg proporciona un posible camino para resolver este posible fallo. Decaf es básicamente una forma de tomar el cofactor de las Twisted Edward’s Curves y cambiarlo matemáticamente con poco costo para el rendimiento y ganancias para la seguridad.

El enfoque del documento Decaf del Grupo Ristretto fue ampliado e implementado en Rust para incluir curvas de cofactor 8 como la Curve25519 y hacer que las firmas Schnorr sobre la curva de Edward sean más seguras.

La Fundación Web3 ha implementado una biblioteca de firmas Schnorr utilizando la compresión Ristretto más segura sobre la Curve25519 en el repositorio Schnorrkel. Schnorrkel implementa protocolos relacionados sobre esta compresión de la curva como HDKD, MuSig, y una función aleatoria verificable (VRF). También incluye varias mejoras menores como el esquema de hashing STROBE que teóricamente puede procesar enormes cantidades de datos con una sola llamada a través de la frontera Wasm.

La implementación de firmas Schnorr que se utiliza en Polkadot y que implementa los protocolos Schnorrkel sobre la compresión Ristretto de la Curve25519 se conoce como sr25519.

¿Se utilizan las firmas BLS en Polkadot? #

Todavía no, pero lo harán. Las firmas BLS permiten una agregación de firmas más eficiente. Como los validadores de GRANDPA suelen firmar lo mismo (por ejemplo, un bloque), tiene sentido agregarlos, lo que puede permitir otras optimizaciones del protocolo.

Como se indica en el README de la biblioteca BLS,

• Las firmas Boneh-Lynn-Shacham (BLS) tienen una firma lenta, una verificación muy lenta, requieren curvas de emparejamiento lentas y mucho menos seguras, y tienden a una peligrosa maleabilidad. Sin embargo, BLS permite una diversa gama de opciones de agregación de firmas mucho más allá de cualquier otro esquema de firma conocido, lo que hace que BLS sea el esquema preferido para votar en algoritmos de consenso y para firmas de umbral.

Aunque las firmas Schnorr permiten la agregación de firmas, las firmas BLS son mucho más eficientes en algunos aspectos. Por esta razón, será una de las claves de sesión que utilizarán los validadores en la red Polkadot y será fundamental para el dispositivo de finalidad GRANDPA.

Recursos #

• Key discovery attack on BIP32-Ed25519 – Publicación en el foro que detalla un posible ataque a BIP32-Ed25519. Una motivación para la transición a la variante sr25519.
• Firmas y claves de cuentas en Polkadot – Mensaje original en el foro por el investigador de Web3 Jeff Burdges.
• ¿Son las firmas Schnorr resistentes a las computadorasa cuánticas?

Apéndice A: Sobre la seguridad de las curvas #

De la introducción de Curve25519 en libssl:

El motivo es el siguiente: Durante el verano de 2013, las revelaciones del ex consultor de [la] NSA Edward Snowden dieron pruebas de que [la] NSA inserta voluntariamente puertas traseras en software, componentes de hardware y estándares publicados. Aunque todavía se cree que las matemáticas detrás de la ECC (criptografía de curva elíptica) siguen siendo sólidas algunas personas (incluyendo a Bruce Schneier [SCHNEIER]), mostraron su falta de confianza en las curvas publicadas por el NIST, como nistp256, nistp384, nistp521, para las que los parámetros constantes (incluido el punto generador) se definen sin explicación. También se cree que [la] NSA tenía algo que decir en su definición. Estas curvas no son las más seguras ni las más rápidas posibles para sus tamaños de clave [DJB], y los investigadores creen que es posible que la NSA tenga formas de crackear las curvas del NIST. También es interesante observar que SSH pertenece a la lista de protocolos que la NSA afirma ser capaz de espiar. Tener un reemplazo seguro haría los ataques pasivos mucho más difíciles, si es que existe tal puerta trasera.

Sin embargo, existe una alternativa en forma de Curve25519. Este algoritmo ha sido propuesto en 2006 por DJB [Curve25519]. Sus principales puntos fuertes son su velocidad, su tiempo de ejecución constante (y la resistencia a los ataques de canal lateral), y su falta de constantes nebulosas codificadas.