Criptografía de umbral y MPC a partir de los principios fundamentales

¿Qué es la criptografía de umbral?

Una clave de firma convencional es una autoridad concentrada. Quien pueda utilizar la clave privada puede firmar, y quien la pierda de forma permanente puede perder el acceso. Las copias de seguridad mejoran la disponibilidad, pero crean copias adicionales de la misma autoridad. La criptografía de umbral cambia la estructura: los participantes poseen partes, y la operación criptográfica se calcula de forma conjunta. El objetivo es lograr que un solo dispositivo, operador o brecha no sea suficiente ni para el robo ni para la pérdida permanente.

El término «umbral» describe una política como «2 de 3» o «3 de 5». En un diseño de firma «2 de 3», cualquier par de participantes autorizados puede completar la operación. Un participante por sí solo no debería poder firmar ni conocer el secreto subyacente. Las partes pueden residir en dispositivos, módulos de seguridad de hardware, servidores, sistemas sin conexión o estar en poder de diferentes personas. La arquitectura es tan importante como la aritmética: tres partes controladas por un único administrador en la nube pueden comportarse como un único dominio de fallo en lugar de como tres partes independientes.

El cálculo multipartito seguro (MPC) es más amplio que las firmas de umbral. El cálculo multipartito seguro estudia cómo las partes pueden evaluar funciones sobre entradas privadas al tiempo que controlan lo que se revela. La generación de claves de umbral, la firma, el descifrado y la generación de aleatoriedad son aplicaciones especializadas. Por lo tanto, una cartera comercializada como «MPC» puede utilizar protocolos, umbrales, diseños de recuperación y modelos de seguridad muy diferentes. La etiqueta por sí sola dice poco sobre las garantías reales.

¿Qué garantiza realmente «t de n»?

Un umbral no es una garantía universal. Los expertos distinguen entre confidencialidad, infalsificabilidad, disponibilidad, robustez y responsabilidad. Un diseño puede proteger la clave y, sin embargo, permitir que un participante malintencionado frustre cada intento de firma. Puede identificar a un saboteador, pero seguir sin poder completar la firma sin sustituir a ese participante. Puede tolerar a un firmante comprometido en un modelo de adversario estático y fallar si un atacante compromete a diferentes firmantes a lo largo del tiempo.

Incluso la frase «menos de t partes no revelan nada» necesita un contexto. El reparto perfecto de secretos de Shamir ofrece una afirmación desde el punto de vista de la teoría de la información sobre las partes matemáticas. Una cartera de umbral implementada también genera transcripciones, compromisos públicos, registros, información temporal y mensajes de error. Esos sistemas circundantes pueden filtrar metadatos, permitir ataques de entrada seleccionada o exponer fallos de implementación sin contradecir el teorema ideal del reparto de secretos.

Conclusión: «t de n» indica el quórum. No indica el modelo de adversario, si un firmante malintencionado puede paralizar el sistema, si las partes se pueden actualizar o si el código ha sido validado de forma independiente.

¿Por qué el reparto de secretos de Shamir no es lo mismo que la firma de umbral?

La construcción de Shamir de 1979 representa un secreto como el término constante de un polinomio aleatorio. Cada participante recibe un punto en ese polinomio. Cualquier umbral requerido permite interpolar el polinomio y recuperar el secreto; si hay menos puntos, el secreto queda indeterminado. Se trata de una forma elegante y potente de proteger copias de seguridad, material en depósito y secretos de recuperación.

La limitación operativa surge cuando es necesario utilizar el secreto. Si la única herramienta disponible es la reconstrucción de Shamir, los participantes autorizados combinan sus fragmentos en una misma máquina, obtienen la clave privada completa y ejecutan un algoritmo de firma convencional. En ese momento, el dispositivo de reconstrucción, la memoria, los registros de proceso, el espacio de intercambio y el operador se convierten en un único punto de exposición. El secreto puede borrarse posteriormente, pero la superficie de ataque ya ha existido.

Una firma de umbral realiza operaciones aritméticas sobre las partes. Los participantes crean valores parciales, demuestran o verifican que dichos valores están bien formados y combinan los resultados parciales en una firma. No es necesario que la clave de firma completa aparezca durante la sesión de firma. Muchos esquemas de umbral utilizan el reparto polinómico al estilo de Shamir como uno de sus componentes. La verdadera distinción se establece entre el almacenamiento de secretos con reconstrucción, por un lado, y un protocolo de firma totalmente distribuido, por otro.

¿Existe alguna vez la clave privada completa?

Distribuidor de confianza

Un distribuidor genera una clave privada normal, crea partes y las distribuye. Esto puede ser seguro si el distribuidor utiliza aleatoriedad sólida, autentica a todos los participantes, verifica los compromisos de reparto y borra de forma fiable el secreto original y las partes no utilizadas. No obstante, crea un momento y un actor con conocimiento de la clave completa. El RFC 9591 sitúa la generación de claves fuera del protocolo FROST principal e incluye un procedimiento de distribuidor de confianza únicamente como apéndice.

Generación distribuida de claves

Un protocolo DKG permite a los participantes aportar aleatoriedad y derivar conjuntamente las partes, además de una clave pública común. Ninguna de las partes debería conocer la clave privada correspondiente, siempre que el protocolo se implemente correctamente y no se supere el umbral de corrupción. El DKG no es un único algoritmo: los distintos esquemas parten de supuestos diferentes sobre las transmisiones, los canales autenticados, las reclamaciones, las partes maliciosas y la disponibilidad de los participantes.

Importación de una clave existente

Es posible que las instituciones deseen conservar una dirección, un historial de cuenta o una clave pública ya existentes. Algunos protocolos admiten la conversión o el uso compartido de una clave existente. Ese proceso puede requerir que el propietario de la clave gestione la clave completa, o bien puede utilizar protocolos de importación especializados. El historial de seguridad previo a la importación sigue siendo relevante: la distribución de una clave no anula una copia, fotografía, copia de seguridad o compromiso anterior.

Recuperación y reconstrucción de emergencia

Algunos sistemas conservan una vía de emergencia que reconstruye la clave a partir de material de copia de seguridad. Esto puede mejorar la recuperación ante desastres y, al mismo tiempo, reintroducir la exposición de la clave única que el diseño de umbral pretendía evitar. Otros sistemas prescinden deliberadamente de cualquier vía de reconstrucción y exigen un umbral de participantes activos para cada acción de recuperación. Ninguna de las dos opciones es automáticamente correcta; la elección debe ser explícita, sometida a pruebas e incluida en el modelo de amenazas.

¿Cómo genera el MPC una firma a partir de varias partes?

Una firma digital es una relación matemática entre un mensaje, una clave pública y material secreto de firma. Los protocolos de umbral aprovechan el álgebra del esquema de firma o utilizan herramientas generales de computación segura, de modo que cada participante contribuye a la relación sin revelar su parte de entrada. Los detalles difieren notablemente entre las firmas de tipo Schnorr y las ECDSA, pero el ciclo de vida operativo tiene etapas comunes.

• Creación de la sesión. El sistema define la clave de grupo, el conjunto de participantes, el umbral, el mensaje exacto, el resumen de firma específico de la cadena, la versión del protocolo y el identificador único de la sesión.
• Validación de la entrada. Cada participante comprueba que el mensaje sea sintácticamente válido y esté permitido por la política. Un protocolo de umbral no debe convertirse en un oráculo de firma para entradas arbitrarias.
• Preparación del nonce o de la prefirma. Los participantes generan valores secretos de un solo uso, compromisos y, en algunos esquemas ECDSA, material de multiplicación. Estos valores deben ser únicos, estar correctamente vinculados a la sesión y protegerse como si se tratara de material de clave.
• Generación de partes de la firma. Al menos t participantes combinan sus partes privadas con la transcripción común para producir firmas parciales o resultados de MPC relacionados.
• Verificación y agregación de partes. Se rechazan las partes no válidas. Un coordinador o todos los participantes combinan las partes válidas en una firma final.
• Verificación ordinaria. La cadena de bloques o la aplicación comprueba la firma final con la clave pública del grupo utilizando su verificador habitual. No es necesario que comprenda el protocolo de umbral interno.

El coordinador es una función del protocolo, no necesariamente un poseedor de claves de confianza. En FROST, por ejemplo, el coordinador puede recopilar compromisos, seleccionar el conjunto de firmantes, distribuir el mensaje y agregar las partes sin recibir las partes privadas. El coordinador aún puede provocar una denegación de servicio, enviar vistas incoherentes o presentar un mensaje malicioso, por lo que siguen siendo necesarias la comunicación autenticada y la validación por parte de los participantes.

¿Por qué son importantes los nonces, el preprocesamiento y los coordinadores?

Los nonces forman parte del secreto

Las firmas Schnorr, EdDSA y ECDSA dependen todas de valores secretos específicos para cada firma, comúnmente denominados «nonces». En la firma habitual de una sola parte, una biblioteca fiable puede generar o derivar el nonce dentro de un entorno de confianza. En un protocolo de umbral, varias partes contribuyen conjuntamente o calculan el estado relacionado con el nonce. Un nonce reutilizado, un compromiso reproducido o un mensaje de multiplicación deliberadamente malformado pueden convertir una o más sesiones de firma en un ataque de extracción de claves. La RFC 9591 advierte explícitamente de que la derivación determinista de nonces, adecuada para el EdDSA convencional, no es segura en un entorno multipartito y requiere la generación de nonces nuevos, uniformemente aleatorios.

El preprocesamiento se realiza antes del mensaje

Muchos sistemas ECDSA de umbral calculan material costoso antes de que se conozca la transacción. De este modo, la fase en línea puede reducirse a un pequeño número de mensajes, lo cual resulta útil para los firmantes en frío y las redes de alta latencia. La contrapartida es operativa: las prefirmas se convierten en inventario criptográfico de un solo uso. La reutilización, la reversión, la duplicación entre réplicas o la pérdida de sincronización del estado pueden ser catastróficas. Las copias de seguridad no deben restaurar las prefirmas consumidas como si estuvieran sin usar.

El enlace de sesión previene los ataques de «mezcla y combinación»

Cada mensaje debe estar vinculado a la versión del protocolo, la clave pública del grupo, el conjunto de participantes, el resumen del mensaje, la cadena, la red, el rol del firmante y una sesión única. Un participante debe rechazar compromisos obsoletos o incoherentes y confirmar que los bytes finales de la transacción son los mismos que los autorizados por la política. Aquí es donde el diseño de la aplicación se une a la criptografía: un núcleo de firma formalmente seguro puede seguir firmando la cadena equivocada, el nonce equivocado, la llamada de contrato equivocada o el destino equivocado si el adaptador proporciona una carga útil incorrecta.

La robustez no es automática

Algunos protocolos garantizan el secreto y la imposibilidad de falsificación, pero se interrumpen cuando un participante actúa de forma indebida. Una interrupción identificable puede señalar al participante responsable del fallo; la robustez tiene como objetivo completar la operación a pesar de la presencia de algunas partes malintencionadas. El RFC 9591 no pretende ser robusto y señala que una capa envolvente de nivel superior, como ROAST, puede hacer frente a las interrupciones maliciosas en algunos entornos.

¿Qué es FROST y qué normaliza el RFC 9591?

FROST aprovecha la estructura lineal de las firmas Schnorr. Cada participante seleccionado posee una parte de la clave de firma del grupo. En la primera ronda, los participantes generan nonces de un solo uso y publican compromisos. En la segunda ronda, calculan las partes de la firma vinculadas al mensaje, al conjunto de firmantes y a los compromisos. El coordinador verifica y suma las partes para obtener la firma Schnorr final.

La distinción entre un RFC de investigación y un estándar de Internet es importante. El RFC 9591 representa el consenso del Grupo de Investigación del Crypto Forum y ofrece a los implementadores una especificación común precisa, pero en su sección de estado se indica que es de carácter informativo y no forma parte de la vía de estandarización de la IETF. El NIST ha iniciado por separado un proceso de evaluación plurianual para los esquemas de umbral; FROST es uno de los esquemas que se están evaluando para esa convocatoria.

¿Es el conjunto de cifrado secp256k1 del RFC compatible con Taproot de Bitcoin?

No de forma automática. El BIP340 de Bitcoin define claves públicas «x-only», hash etiquetados, una ecuación de desafío específica y una codificación de 64 bytes. El conjunto de cifrado FROST secp256k1 del RFC 9591 utiliza su propia construcción de hash con dominios separados y un manejo genérico de puntos comprimidos. Un protocolo puede utilizar la misma curva y, aun así, generar firmas que un verificador BIP340 rechace. Por lo tanto, un Schnorr de umbral compatible con Bitcoin necesita una construcción y una implementación diseñadas explícitamente para la semántica del BIP340.

Conclusión: «Utiliza secp256k1» no es un certificado de compatibilidad. La curva es solo una capa de un sistema de firma.

¿Por qué es más complejo el ECDSA umbral que el Schnorr umbral?

De forma simplificada, una firma ECDSA contiene un valor s = k^-1(H(m) + r x) mod q, donde x es la clave privada y k es un nonce de un solo uso. En un escenario de umbral, ninguna de las partes debe conocer ni x ni k. Por lo tanto, los participantes deben obtener partes aditivas o polinómicas de los productos que involucran a x y k y, en última instancia, de la expresión relacionada con la inversa, al tiempo que se impide que una parte malintencionada elija valores mal formados que revelen otra parte.

Los protocolos basados en Paillier utilizan cifrado homomórfico aditivo y subprotocolos de «multiplicación a suma» (MtA). Otras familias utilizan grupos de clases o transferencia inconsciente. Las pruebas de conocimiento cero o los controles de consistencia demuestran que los valores cifrados y las partes se encuentran dentro de los rangos requeridos y satisfacen las relaciones del protocolo. Estos componentes crean una superficie de implementación mayor que la del protocolo Schnorr de umbral: aritmética de números enteros grandes, sistemas de prueba, gestión de transcripciones, preprocesamiento, atribución de fallos y múltiples supuestos criptográficos.

El ECDSA umbral sigue siendo importante porque el legado de Bitcoin y los gastos de claves de SegWit v0, las cuentas de propiedad externa de Ethereum y muchos otros sistemas implementados verifican ECDSA. La compatibilidad con las direcciones y el hardware existentes puede justificar la complejidad, pero la elección debe hacerse siendo plenamente consciente de que la superficie de ataque es mayor.

¿Qué familias de protocolos ECDSA umbral son relevantes?

El campo evoluciona rápidamente y los apodos de los protocolos suelen utilizarse de forma imprecisa. Los implementadores deben identificar la revisión exacta del artículo, el conjunto de parámetros, la prueba de seguridad y la versión del código. Una biblioteca descrita como «GG18» puede incorporar parches posteriores, omitir pruebas necesarias, añadir un preprocesamiento propio o implementar una variante más antigua y vulnerable. El año que figura en un apodo no constituye una garantía de seguridad suficiente.

El artículo no clasifica estos protocolos. El rendimiento depende del número de participantes, la geografía, el umbral, el preprocesamiento, el hardware, los supuestos de disponibilidad y la calidad de la implementación. Un artículo más reciente no es automáticamente más seguro que una implementación madura, y una implementación madura no es segura simplemente porque el artículo en el que se basa haya sido bien estudiado.

¿En qué se diferencian FROST, MuSig2 y la multifirma ordinaria?

A veces se denomina a MuSig2 «firma de umbral» porque cooperan varias partes. El BIP327 deja claro que se trata de un esquema de multifirma n-de-n, no de una firma de umbral t-de-n. Cada clave utilizada en la agregación sigue siendo una clave de firma completa. Si un participante no está disponible, el grupo no puede firmar a menos que exista una ruta alternativa independiente.

Taproot complica la comparación de la visibilidad. Un gasto mediante una ruta de clave agregada de MuSig2 u otro sistema puede parecer un gasto BIP340 ordinario con un único firmante, y las rutas de script opcionales permanecen ocultas a menos que se utilicen. Un gasto mediante una ruta de script revela la rama ejecutada y la prueba, pero no necesariamente todas las ramas no utilizadas. Por lo tanto, la afirmación de que «la multifirma es visible, mientras que la de umbral es invisible» es demasiado absoluta.

Firma por umbral frente a multisig en cadena: ¿qué compensaciones cambian?

La comparación no es una clasificación universal. El script de Bitcoin, Taproot y las cuentas de contratos inteligentes de Ethereum ofrecen diferentes capacidades. Algunas cadenas admiten la multifirma nativa de forma eficiente; otras requieren carteras de contrato o carecen por completo de un script flexible. La firma por umbral puede hacer que la cadena vea una firma familiar, pero el protocolo fuera de cadena pasa a formar parte de la base de computación de confianza.

Un diseño útil puede combinar ambas opciones. Por ejemplo, una salida de Taproot puede utilizar una ruta de clave agregada o de umbral para los gastos rutinarios y conservar rutas de script ocultas para la recuperación con retraso temporal o de emergencia. Una cuenta inteligente de Ethereum puede requerir una firma ECDSA generada por umbral, además de límites a nivel de contrato. La estructura por capas puede reducir un riesgo y añadir complejidad operativa, por lo que cada rama de recuperación debe someterse a pruebas, en lugar de limitarse a documentarla.

¿Funciona una firma de umbral en cualquier cadena de bloques?

Una pila de firmas de cadena de bloques tiene varias capas: la curva matemática, la ecuación de firma, la codificación de la clave pública, la codificación de la firma, la serialización de la transacción, el resumen de la firma, la separación de dominios, las reglas de valores canónicos y la semántica de cuentas o scripts. La firma umbral debe coincidir con todas ellas. La frase «funciona en cualquier cadena con la misma curva» pasa por alto la mayor parte de esta pila.

Bitcoin

Los gastos con claves heredadas y SegWit v0 utilizan ECDSA, mientras que las firmas de ruta de clave de Taproot utilizan Schnorr BIP340. El BIP340 cuenta con claves específicas «solo x» y hash etiquetado. MuSig2 BIP327 está diseñado explícitamente para el BIP340. Una biblioteca genérica de ECDSA con umbral o FROST necesita un adaptador de Bitcoin que gestione la construcción del sighash, el tipo de script, el ajuste de claves, las reglas de nonce y la codificación de firmas aceptada.

Ethereum

Las cuentas de titularidad externa utilizan ECDSA secp256k1 y recuperan una dirección a partir de los componentes de la firma. Los tipos de transacción de Ethereum, los ID de cadena y los datos estructurados de EIP-712 utilizan dominios de firma distintos. La EIP-2 rechaza las firmas de transacciones «high-s». Por lo tanto, un firmante umbral debe generar valores canónicos de r y s, además de la información de recuperación correcta para la carga útil exacta.

Sistemas basados en Ed25519

El RFC 9591 incluye conjuntos compatibles con Ed25519 y Ed448 cuyas firmas finales pueden verificarse mediante los verificadores estándar correspondientes. La aplicación aún debe proporcionar el mensaje de cadena exacto, el formato de la clave pública y la política de transacciones. La compatibilidad del verificador no valida la integración con el monedero correspondiente.

¿Cómo funcionan la actualización, el reasignado, la recuperación y los cambios en la composición del grupo?

Actualización proactiva

Una actualización añade una parte igual a cero o, en su defecto, vuelve a aleatorizar las partes de modo que el secreto subyacente del grupo permanezca igual. Las partes antiguas deberían quedar inutilizables tras la actualización. En un modelo de seguridad proactivo, un atacante que comprometa a diferentes participantes a lo largo del tiempo debe reunir un umbral en un solo periodo de actualización, en lugar de acumular partes indefinidamente. La actualización no repara un compromiso que ya haya alcanzado el umbral, ni borra las copias que un atacante pueda haber realizado de las credenciales de la aplicación o de los sistemas de políticas.

Nueva distribución de participaciones y sustitución de participantes

Un protocolo de redistribución de participaciones puede distribuir nuevas participaciones a un nuevo conjunto de participantes y puede cambiar t o n, conservando al mismo tiempo la misma clave pública del grupo. Esto permite sustituir un dispositivo perdido, rotar a un empleado o modificar el control organizativo sin mover fondos en la cadena. Solo es posible cuando el protocolo lo admite y coopera un conjunto suficiente de personas autorizadas. Un producto no puede «recrear» una participación perdida partiendo de la nada.

¿Qué ocurre cuando se pierde una parte?

Si quedan al menos t partes válidas, el grupo normalmente puede seguir firmando. Es posible que pueda crear una sustitución mediante el reasignación de partes. Si sobreviven menos de t partes y no hay una clave de recuperación independiente, una copia de seguridad o una ruta de contrato, la autoridad de firma desaparece. Un esquema de umbral mejora la redundancia; no garantiza la recuperación ante todos los patrones de pérdida.

¿Qué ocurre cuando se roba una parte?

En un modelo ideal de reparto de secretos «t de n», un número de partes inferior a t no revela el secreto y no permite firmar. Desde el punto de vista operativo, una parte robada sigue constituyendo un incidente de seguridad activo. El atacante puede utilizarla en sesiones de protocolo, combinarla con futuras vulnerabilidades, aprovechar errores de implementación u obtener metadatos. La respuesta correcta es detener las sesiones de riesgo, investigar, actualizar o volver a repartir las partes, rotar las credenciales relacionadas y verificar que los participantes restantes sean independientes.

¿Cuáles son los principales supuestos de seguridad y modos de fallo?

La seguridad contra el aborto es diferente de la seguridad contra el robo

Muchos protocolos de mayoría deshonesta preservan el secreto incluso cuando un participante malintencionado interrumpe la sesión. Eso es un resultado criptográfico satisfactorio y un resultado operativo fallido. Los sistemas de tesorería deben definir con qué rapidez se puede excluir a un participante malintencionado, si existen subconjuntos de firmantes alternativos, cómo se cancelan las sesiones caducadas y cómo continúa la actividad durante una disputa.

El coordinador puede no ser secreto y seguir siendo poderoso

Un coordinador puede seleccionar a los firmantes, recopilar compromisos, elegir el mensaje, programar sesiones y publicar la firma final. Incluso sin compartir claves, puede observar metadatos, censurar solicitudes, dividir las vistas de los participantes o desencadenar repetidamente tareas costosas. Los mensajes del protocolo deben autenticarse, los participantes deben derivar o validar de forma independiente la transacción, y la supervisión debe distinguir entre un fallo ordinario y un comportamiento adversario.

La firma por umbral no es postcuántica por defecto

FROST, ECDSA y los sistemas Schnorr actuales se basan en supuestos sobre el logaritmo discreto. Dividir una clave no hace que el algoritmo de firma subyacente sea resistente a un ordenador cuántico suficientemente potente. Las firmas de umbral poscuánticas son un área activa de investigación y normalización, y la planificación de la migración debe tener en cuenta tanto el verificador de la cadena como la capa de gestión distribuida de claves.

¿Qué demostraron Alpha-Rays, TSSHOCK y las investigaciones posteriores sobre extracción de claves?

Alpha-Rays

La investigación de Alpha-Rays de 2021 describió ataques de extracción de claves contra implementaciones de ECDSA con umbral de tipo GG18 y GG20. Los ataques se centraron en los subprotocolos de «multiplicación a suma» y en decisiones de implementación como los modos «rápidos» sin las pruebas de rango requeridas. Un participante malintencionado podía aprovechar la interacción para recuperar la clave completa. El resultado no supuso una brecha en la seguridad de ECDSA, sino que demostró que omitir los pasos de prueba y validación invalida el argumento de seguridad.

TSSHOCK

TSSHOCK, dado a conocer en 2023, documentó ataques adicionales contra implementaciones de ECDSA con umbral. La investigación se centró en fallos de implementación en el cifrado homomórfico y en el manejo de pruebas, y mostró varias vías para la recuperación de la clave privada. La lección importante va más allá de los ataques mencionados: los protocolos ECDSA con umbral son sensibles a los rangos exactos, la validación de parámetros, las declaraciones de prueba y el manejo de errores.

BitGo Zero Proof

Una vulnerabilidad de la cartera BitGo, revelada públicamente y detectada por Fireblocks, ilustró el mismo patrón en una integración en producción. La falta de validación de pruebas en un flujo ECDSA entre dos partes podría permitir que una de ellas extrajera la parte correspondiente a la otra y reconstruyera la clave. El servicio afectado se suspendió y se corrigió tras la revelación. Una vez más, el fallo no radicaba en la primitiva ECDSA, sino en la implementación del protocolo y en la falta de un límite de verificación.

Investigación práctica sobre la extracción de claves en 2024

Investigaciones posteriores, tanto académicas como del sector, analizaron las principales implementaciones de carteras MPC y documentaron ataques de extracción de claves que requerían diferentes números de interacciones de firma; en un caso, tan solo una firma en las condiciones estudiadas. Estos resultados refuerzan la necesidad de identificar las versiones exactas de los protocolos, incluir todos los pasos de prueba y validación, y considerar la revisión de la implementación como parte de la garantía de seguridad criptográfica.

¿Cómo debe evaluarse una implementación de MPC o de firma de umbral?

Especificación criptográfica

• Indica el artículo exacto, la revisión, el conjunto de cifrado y el conjunto de parámetros. Confirma si la implementación coincide con la versión cuya prueba se cita.
• Documenta el umbral, el número de participantes, el modelo de corrupción estático o adaptativo, la hipótesis de mayoría honesta o deshonesta, el comportamiento en caso de aborto y las afirmaciones de robustez.
• Confirme cómo se generan o importan las claves, si existe un distribuidor de confianza y si se crea alguna vez una clave completa o una copia de seguridad reconstruible.
• Identifica todas las primitivas auxiliares: parámetros de Paillier, transferencia inconsciente, grupos de clases, compromisos, pruebas de conocimiento cero, funciones hash y generadores de números aleatorios.

Implementación y pruebas

• Exige una revisión independiente por parte de especialistas en la familia concreta de protocolos, no solo una auditoría general de contratos inteligentes o de aplicaciones.
• Pruebe todas las rutas negativas: puntos malformados, escalares, pruebas, textos cifrados, identificadores de participantes, conjuntos de firmantes, nonces duplicados, mensajes reproducidos y sesiones abortadas.
• Utilizar primitivas de tiempo constante y resistentes a canales laterales adecuadas al entorno del dispositivo; proteger los registros, los volcados de memoria, el intercambio de memoria, la telemetría y los sistemas de observabilidad.
• Verificar con vectores de prueba publicados y crear pruebas de interoperabilidad entre implementaciones cuando exista una especificación.
• Mantener un proceso de respuesta ante vulnerabilidades que permita revocar a los participantes, suspender la firma, actualizar los recursos compartidos y migrar los fondos sin ocultar el impacto operativo.

Arquitectura operativa

• Colocar las participaciones en dominios de fallo verdaderamente independientes: credenciales, administradores, dispositivos y redes diferentes y, preferiblemente, raíces de software o hardware distintas cuando sea posible.
• Proteger el estado de la prefirma y del nonce contra la reversión, la clonación y la restauración de copias de seguridad. Tratar el estado consumido como consumido de forma permanente.
• Autenticar los mensajes de los participantes y proporcionar a cada firmante datos de transacción suficientes para validar la acción económica, no solo un hash sin contexto.
• Simule situaciones de pérdida, compromiso de datos, salida de empleados, interrupción del servicio en la nube, fallo del coordinador y recuperación ante desastres. Un plan de recuperación que nunca se ha ejecutado es una mera suposición.
• Supervisa los intentos de firma, la selección de participantes, las pruebas fallidas, los eventos de actualización y las anulaciones de políticas. La privacidad criptográfica no debe eliminar la responsabilidad operativa.

Preguntas frecuentes

¿Es la MPC lo mismo que las firmas de umbral?

No. La MPC es la disciplina general que se ocupa del cálculo sobre entradas privadas en poder de varias partes. La firma umbral es una aplicación de la MPC que genera una firma digital mediante una clave de grupo compartida. Otras aplicaciones de la MPC incluyen el descifrado umbral, la intersección de conjuntos privados y la generación conjunta de aleatoriedad.

¿Tiene una cartera de umbral una clave privada?

Tiene autoridad de firma correspondiente a una clave pública, pero esa autoridad puede existir únicamente en forma de partes distribuidas. En un diseño basado en DKG, ningún participante posee nunca la clave privada completa. En un diseño de «dealer», «import» o «reconstruction», puede existir una clave completa en alguna fase.

¿Puede una parte robada permitir el robo de los fondos?

En un esquema t-de-n correctamente implementado, un número de partes inferior a t no debería generar una firma ni revelar la clave. El robo de una parte sigue siendo un incidente: el atacante podría combinarla con otras vulnerabilidades posteriores, abusar de las sesiones del protocolo o aprovechar fallos de implementación. Actualiza o vuelve a compartir cuando el diseño lo permita.

¿Se puede sustituir una parte perdida?

Solo si quedan suficientes partes autorizadas y el protocolo o la arquitectura de recuperación admiten el reasignación de partes. Los participantes que hayan sobrevivido pueden, en ocasiones, crear una nueva parte conservando la clave pública. Si sobreviven menos de las partes necesarias para alcanzar el umbral y no existe una vía de recuperación independiente, la clave no se puede recuperar.

¿Es FROST un estándar oficial de Internet?

No. El RFC 9591 es una publicación informativa del IRTF que recoge el consenso del Grupo de Investigación del Foro de Criptografía. Se trata de una especificación compartida precisa, pero no es un documento de la vía de estandarización de la IETF. El NIST está evaluando por separado las propuestas de esquemas de umbral mediante un proceso cuya convocatoria formal se inició en 2026.

¿Incluye el RFC 9591 la generación de claves?

La especificación principal abarca la firma FROST de dos rondas. La generación de claves queda explícitamente fuera de su ámbito principal. En un apéndice se ofrece un ejemplo de «distribuidor de confianza», y las implementaciones pueden utilizar un protocolo DKG independiente.

¿Es FROST secp256k1 compatible con Taproot de Bitcoin?

El RFC incluye un conjunto de cifrado secp256k1, pero eso no lo hace automáticamente compatible con BIP340. Bitcoin utiliza claves específicas «solo x», hash etiquetados y reglas de codificación. Una implementación de Bitcoin necesita una construcción de umbral específica para BIP340 y un adaptador de cadena.

¿Es MuSig2 una firma de umbral?

MuSig2 es un esquema de multifirma que agrega claves Schnorr independientes y requiere a los n firmantes. El BIP327 lo describe explícitamente como «n de n», en lugar de como un esquema general de firma de umbral «t de n».

¿Se puede detectar en la cadena de bloques que se ha utilizado MPC?

A menudo no, solo a partir de la firma final: se verifica como una firma ordinaria bajo una única clave pública. El tipo de dirección, el código del contrato, los patrones de transacción, los metadatos del servicio o revelaciones posteriores aún pueden desvelar el diseño de custodia. Taproot también puede ocultar algunas políticas de multifirma y de scripts, por lo que la invisibilidad no es exclusiva de la MPC.

¿Es la firma por umbral más segura que la multifirma?

Ninguna de las dos es universalmente más segura. La multifirma ofrece una política más sencilla impuesta por la cadena y claves completas independientes; la firma por umbral puede reducir la huella en la cadena, ocultar el quórum y preservar una dirección mediante el reenvío compartido. Los protocolos de umbral añaden complejidad criptográfica y de implementación fuera de la cadena. La elección correcta depende de la cadena, el modelo de amenazas, las necesidades de recuperación y la capacidad operativa.

¿Protege la firma por umbral contra las estafas?

Puede requerir varias aprobaciones e imponer límites, pero un quórum legítimo aún puede firmar una transacción maliciosa. Los participantes y los sistemas de políticas deben comprender el destino exacto, el importe, la llamada al contrato, la red y los permisos antes de generar las partes.

¿Es la criptografía de umbral poscuántica?

Los esquemas de umbral actuales, como FROST, Schnorr y ECDSA, no son poscuánticos. Distribuyen la autoridad de firma existente, pero mantienen los supuestos de seguridad del algoritmo de firma subyacente. Los esquemas de umbral poscuánticos requieren primitivas diferentes y compatibilidad con la cadena.

Conclusión

La criptografía de umbral resuelve un problema operativo real: un único secreto de firma no debe decidir el destino de un saldo, un sistema o una institución de gran envergadura. La solución no consiste simplemente en dividir una clave en fragmentos. Un diseño completo de firma de umbral debe definir cómo se generan las partes, cómo se protege la aleatoriedad de un solo uso, cómo los participantes llegan a un acuerdo sobre un mensaje, cómo se rechazan las contribuciones malformadas, cómo se atribuyen los fallos, cómo se actualizan las partes y cómo la firma final coincide con la cadena de destino.

La corrección más importante al lenguaje habitual del marketing es que toda afirmación es condicional. Un sistema basado en DKG puede prescindir de una clave completa durante toda su vida útil; un sistema de clave importada no puede presumir del mismo historial. Una parte aislada puede ser criptográficamente insuficiente y operativamente urgente. Una firma puede parecer ordinaria en la cadena, aunque dependa de una gran base de computación de confianza fuera de la cadena. Un protocolo puede demostrarse seguro y, sin embargo, implementarse de forma insegura.

Si se utiliza con dominios de fallo independientes, código auditado, una disciplina estricta en el uso de nonces, adaptadores de cadena correctos, procedimientos de recuperación ensayados y firmantes que validan lo que aprueban, la firma por umbral puede eliminar el punto único de fallo sin sacrificar la compatibilidad con la verificación de firmas habitual. Si se utiliza como etiqueta sin esos controles, puede ocultar un punto único de fallo más complejo.

Fuentes y lecturas recomendadas

Referencias clave para este artículo, actualizadas a julio de 2026.

• Proyecto de criptografía de umbral multipartita del NIST. https://csrc.nist.gov/projects/threshold-cryptography
• NIST IR 8214: Esquemas de umbral para primitivas criptográficas. https://csrc.nist.gov/pubs/ir/8214/final
• NIST IR 8214A: Hoja de ruta hacia los criterios para esquemas de umbral. https://csrc.nist.gov/pubs/ir/8214/a/final
• NIST IR 8214C: Primera convocatoria para esquemas de umbral multipartitos. https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8214C.pdf
• Adi Shamir, «Cómo compartir un secreto». https://dl.acm.org/doi/10.1145/359168.359176
• RFC 9591: Firmas Schnorr de dos rondas FROST. https://www.rfc-editor.org/info/rfc9591/
• Komlo y Goldberg, FROST. https://eprint.iacr.org/2020/852
• BIP340: Firmas Schnorr para secp256k1. https://bips.dev/340/
• BIP327: MuSig2 para multifirmas compatibles con BIP340. https://bips.dev/327/
• BIP341: Taproot. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
• Gennaro y Goldfeder, ECDSA de umbral multipartito rápido con configuración rápida sin necesidad de confianza. https://dl.acm.org/doi/10.1145/3243734.3243859
• Gennaro y Goldfeder, «ECDSA de umbral de una ronda con interrupción identificable». https://eprint.iacr.org/2020/540
• Canetti et al., ECDSA de umbral no interactivo, proactivo y con abortos identificables en UC. https://eprint.iacr.org/2021/060
• Doerner et al., «ECDSA de umbral a partir de los supuestos de ECDSA: el caso multipartito». https://eprint.iacr.org/2019/523