Resumen
- FROST combina las participaciones de un subconjunto que alcanza el umbral y entrega una firma
(R, z)verificable con una única clave pública de grupo. - El resultado no enumera a los participantes ni demuestra su autoridad empresarial. Para atribuir la decisión hacen falta el transcript de dos rondas, la identidad autenticada y el dictamen local sobre el mensaje.
Lo que sabe el verificador y lo que ya no puede ver
Imaginemos un grupo de siete custodios y un umbral de cuatro. La verificación final responde una pregunta exacta: ¿coinciden mensaje, firma y clave pública conforme a la ecuación Schnorr? No responde cuál de las combinaciones posibles produjo la firma. Tampoco dice si los cuatro operadores eran empleados vigentes, representantes autorizados o servicios automáticos que firmaron un resumen opaco.
FROST persigue precisamente una salida compacta. Algunas suites generan firmas compatibles con verificadores Ed25519 o Ed448. La aplicación receptora no necesita entender las dos rondas ni cada participación. Esa compatibilidad reduce el acoplamiento técnico y, al mismo tiempo, elimina de la salida los datos que una auditoría de gobierno querría inspeccionar.
Por eso «firma del grupo» y «decisión del grupo» no son sinónimos. La primera se resuelve con criptografía. La segunda exige saber quién tenía capacidad de decidir, qué vio y qué regla convirtió su respuesta en permiso.
La composición de la sesión no nace de FROST
Cada miembro tiene un identificador distinto, una parte secreta y una clave pública asociada. Todos conocen la clave pública grupal. En el modo coordinado, una entidad externa elige al menos el mínimo de participantes, reparte los datos de las rondas, recibe las participaciones, las suma y publica la firma.
El RFC declara expresamente que la elección del coordinador y del conjunto firmante es externa al protocolo. También describe una modalidad sin coordinador único. En ella todos hablan con todos, pero sigue existiendo una decisión previa sobre miembros, umbral, mensaje y momento de publicación.
El número usado como identificador criptográfico no prueba la identidad civil o corporativa. La evidencia operativa debe vincularlo con un principal autenticado y con una versión temporal del padrón. Si una persona cambia de puesto o abandona la organización, mantener viva su parte no conserva mágicamente el mandato anterior.
Dos rondas para construir una sola firma
La primera ronda genera dos nonces secretos por participante y publica dos compromisos. La segunda recibe el mensaje y la lista completa y ordenada de compromisos. A partir de la clave grupal, el mensaje, la lista y cada identificador se calculan factores de enlace; luego cada firmante devuelve su participación.
Este estado es irrepetible. Los nonces deben proceder de aleatoriedad segura, no pueden usarse en más de una llamada a sign y deben borrarse al terminar. Repetirlos no provoca sólo un error de auditoría: puede permitir recuperar por completo la parte secreta del participante.
La continuidad del conjunto también importa. RFC 9591 rechaza como no recomendada una optimización que reduce multiplicaciones porque deja de garantizar que el conjunto de la primera ronda sea el mismo que produce la firma en la segunda. La optimización conserva una salida verificable, pero reduce lo que puede afirmarse sobre el recorrido interno.
El recibo desaparece cuando se agrega
El coordinador suma las participaciones y obtiene R y z. El formato final no incluye el umbral, los identificadores, la lista de compromisos, las participaciones ni las decisiones locales. Si el transcript no se protege antes de publicar la firma, la atribución se pierde por diseño.
Antes de agregar, cada participación puede verificarse con la clave pública individual, los compromisos, la lista completa, el mensaje y la clave grupal. Si aparece una participación inválida, el coordinador puede identificar al participante matemático. Para convertir ese identificador en un origen responsable necesita un canal autenticado.
La ausencia es distinta del engaño. FROST no identifica por sí mismo al participante que simplemente no responde. La aplicación puede registrar entrega, plazo y silencio; no debe inventar a partir de ello una intención maliciosa. La medida correctiva, incluida una eventual exclusión futura, está fuera del alcance del RFC.
Firmar los bytes no aprueba necesariamente el acto
El texto recomienda que las aplicaciones validen sus entradas para no convertir a los miembros en oráculos de firma. En una transacción, cada participante puede necesitar examinar sintaxis, importe, destino y voluntad de los interesados. En TLS puede exigir los mensajes originales del handshake antes de aceptar el hash del transcript.
Una participación válida sólo demuestra que una parte de clave calculó sobre el mensaje entregado por el protocolo. No demuestra que la interfaz presentó el mismo objeto, que se ejecutó una política vigente, que el aprobador no tenía conflicto ni que el sistema receptor hará lo que el firmante creyó revisar.
La cadena verificable conserva por separado el objeto canónico, su representación firmada, el resultado de validación local, la identidad y función del participante, el resultado de agregación, la publicación y la acción posterior. La firma enlaza algunos eslabones; no los crea todos.
FROST tampoco promete robustez
Un miembro que entrega una participación incorrecta o se niega a cooperar puede impedir la firma. RFC 9591 dice que FROST no ofrece robustez y que el protocolo debe abortar ante determinados fallos. ROAST es un protocolo envolvente distinto para entornos que necesitan tolerar mejor participantes disruptivos.
Además, FROST se basa en el problema del logaritmo discreto y no es poscuántico. El documento es Informativo, procede de la IRTF y refleja consenso del CFRG; no es una norma IETF ni una orden de adopción. Los vectores y una prueba de biblioteca no prueban un despliegue con control de nonces, padrón actualizado, canales autenticados y archivo de sesiones.
La primacía del código en ejecución exige observar cada capa. La firma válida es realidad criptográfica. La etiqueta «aprobado por el consejo» es una afirmación institucional. Para que ambas coincidan hacen falta mandatos y registros, no sólo una ecuación correcta.
Fuentes
- RFC 9591 — The FROST Protocol
- Registro de RFC Editor para RFC 9591
- Registro de Datatracker para RFC 9591
- RFC 8032 — Edwards-Curve Digital Signature Algorithm
- RFC 9496 — The ristretto255 and decaf448 Groups
- RFC 4086 — Randomness Requirements for Security
- FROST: Flexible Round-Optimized Schnorr Threshold Signatures
- ROAST: Robust Asynchronous Schnorr Threshold Signatures
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification and Localized Future Decision
- Lu Heng — Reality Layers and Symbolic Power
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

