Threshold Encryption: criptografía sin punto único de fallo

Introducción: el problema del punto único de fallo

En febrero de 2014, Mark Karpelès, director ejecutivo de Mt. Gox —por entonces la mayor plataforma de intercambio de Bitcoin del mundo—, publicó un escueto comunicado anunciando la suspensión de todas las operaciones. En los días siguientes, la realidad se hizo evidente: aproximadamente 850.000 bitcoins, valorados entonces en unos 450 millones de dólares, habían desaparecido. Miles de usuarios perdieron sus ahorros de la noche a la mañana. La causa última se redujo a un problema desoladoramente simple: las claves privadas que controlaban los fondos estaban concentradas en un único punto, gestionadas por un número reducido de personas, sin mecanismos de distribución ni redundancia criptográfica.

Apenas cinco años después, en diciembre de 2018, Gerald Cotten —fundador de QuadrigaCX, la mayor plataforma de criptomonedas de Canadá— falleció inesperadamente durante un viaje a India. Cotten era la única persona con acceso a las claves privadas de los monederos fríos de la plataforma. Con su muerte, aproximadamente 190 millones de dólares canadienses quedaron atrapados para siempre en direcciones criptográficas a las que nadie más podía acceder. Las investigaciones posteriores revelaron que no existía ningún protocolo de recuperación, ningún respaldo distribuido, ninguna forma de reconstruir el acceso sin la participación de Cotten. Sus clientes —más de 76.000 personas— presentaron reclamaciones que, en muchos casos, representaban los ahorros de toda una vida.

Estos no son casos aislados. Son la manifestación más dramática de un problema estructural que afecta a cualquier sistema que dependa de un secreto centralizado: una contraseña maestra, una clave de cifrado, un certificado raíz. Cuando ese secreto existe como una única pieza de información en un único lugar, basta un fallo —un hackeo, un accidente, una muerte, un empleado desleal— para que todo el sistema colapse. Los criptógrafos llaman a esto el problema del punto único de fallo (single point of failure), y durante décadas ha sido el talón de Aquiles de la seguridad digital.

La solución no pasa por crear claves más largas o por almacenarlas en bóvedas más seguras. La solución, como veremos a lo largo de este artículo, consiste en eliminar la clave como objeto único. En lugar de confiar un secreto a una sola entidad, se fragmenta de tal manera que ningún participante individual posea información suficiente para reconstruirlo, pero un grupo suficiente de participantes —un umbral— pueda colaborar para utilizarlo sin que el secreto completo se materialice jamás en ningún lugar. Esto es, en esencia, lo que conocemos como criptografía de umbral (threshold cryptography).

Shamir's Secret Sharing: dividir un secreto sin romperlo

La idea intuitiva

Imaginemos que el presidente de un banco necesita proteger la combinación de la caja fuerte principal. Si la memoriza solo él, cualquier accidente lo deja inaccesible. Si se la da a sus cinco directivos, cualquiera de ellos podría abrir la caja por su cuenta, lo que multiplica el riesgo. Lo que necesita es un mecanismo intermedio: repartir la combinación entre los cinco directivos de tal forma que hagan falta al menos tres de ellos para reconstruirla, pero que dos cualesquiera —por mucho que se confabulen— no obtengan absolutamente ninguna información útil sobre la combinación original.

En 1979, el criptógrafo israelí Adi Shamir (el mismo que pone la "S" en RSA) publicó un método elegante para lograr exactamente esto. Su técnica se basa en una propiedad matemática que cualquier persona puede entender si empezamos por lo más básico: los polinomios.

Polinomios: empezando desde cero

Un polinomio es, en el fondo, una receta para dibujar una curva. La receta más simple es una línea recta. Cuando en el colegio escribíamos y = 2x + 3, estábamos describiendo una línea recta: para cada valor de x, obtenemos un valor de y. Si x = 0, entonces y = 3. Si x = 1, entonces y = 5. Si x = 4, entonces y = 11. Esa ecuación es un polinomio de grado 1 (la potencia más alta de x es 1).

Si añadimos un término con x², obtenemos una parábola: y = x² + 2x + 3. Ahora la curva ya no es recta, sino que se curva. Este es un polinomio de grado 2. Si añadimos x³, el grado sube a 3, y así sucesivamente.

La propiedad clave que Shamir aprovechó es esta: para definir de forma única un polinomio de grado t-1, necesitas exactamente t puntos. Piénsalo así: para trazar una línea recta (grado 1) necesitas al menos 2 puntos. Con un solo punto podrían pasar infinitas rectas. Para definir una parábola (grado 2) necesitas 3 puntos. Con solo 2 puntos, infinitas parábolas diferentes podrían pasar por ellos. Esta propiedad geométrica es la piedra angular de todo el sistema.

El método paso a paso: un ejemplo numérico

Supongamos que nuestro secreto es el número 42 (la combinación de la caja fuerte), y queremos repartirlo entre 5 personas de modo que cualesquiera 3 puedan reconstruirlo. Necesitamos un polinomio de grado 2 (porque t - 1 = 3 - 1 = 2).

Paso 1: Construir el polinomio. El secreto se coloca como el término independiente (el valor cuando x = 0). Los demás coeficientes se eligen al azar. Digamos que elegimos:

f(x) = 42 + 7x + 3x²

El secreto 42 es el valor f(0). Los coeficientes 7 y 3 son aleatorios y se descartan después de generar los fragmentos.

Paso 2: Generar los fragmentos (shares). Evaluamos el polinomio en los puntos x = 1, 2, 3, 4, 5 (uno para cada participante):

• Participante 1: f(1) = 42 + 7(1) + 3(1²) = 42 + 7 + 3 = 52
• Participante 2: f(2) = 42 + 7(2) + 3(2²) = 42 + 14 + 12 = 68
• Participante 3: f(3) = 42 + 7(3) + 3(3²) = 42 + 21 + 27 = 90
• Participante 4: f(4) = 42 + 7(4) + 3(4²) = 42 + 28 + 48 = 118
• Participante 5: f(5) = 42 + 7(5) + 3(5²) = 42 + 35 + 75 = 152

Cada participante recibe su par (x, f(x)). El participante 1 recibe (1, 52), el participante 2 recibe (2, 68), y así sucesivamente. El polinomio original y sus coeficientes aleatorios se destruyen.

Reconstrucción: la interpolación de Lagrange

Supongamos que los participantes 1, 3 y 5 se reúnen para reconstruir el secreto. Tienen los puntos (1, 52), (3, 90) y (5, 152). Necesitan encontrar el valor de f(0) —el secreto— sin reconstruir todo el polinomio. Para ello usan la interpolación de Lagrange, un método que Joseph-Louis Lagrange describió en el siglo XVIII.

La idea es construir unos "pesos" especiales para cada punto, llamados coeficientes de Lagrange. Para el punto x₁ = 1, el peso se calcula usando los otros dos valores de x:

λ₁ = (0 - 3)(0 - 5) / (1 - 3)(1 - 5) = (-3)(-5) / (-2)(-4) = 15 / 8

Para x₂ = 3:

λ₂ = (0 - 1)(0 - 5) / (3 - 1)(3 - 5) = (-1)(-5) / (2)(-2) = 5 / (-4) = -5/4

Para x₃ = 5:

λ₃ = (0 - 1)(0 - 3) / (5 - 1)(5 - 3) = (-1)(-3) / (4)(2) = 3 / 8

El secreto se obtiene multiplicando cada peso por su valor correspondiente y sumando:

f(0) = λ₁·52 + λ₂·90 + λ₃·152 = (15/8)·52 + (-5/4)·90 + (3/8)·152

= 97,5 + (-112,5) + 57 = 42

El secreto original ha sido reconstruido exactamente. Cualquier combinación de 3 participantes habría llegado al mismo resultado, porque 3 puntos definen de forma única una parábola.

¿Por qué dos participantes no pueden saber nada?

Si solo dos de los cinco participantes se reúnen —digamos los que tienen (1, 52) y (2, 68)—, saben que el secreto es f(0) para alguna parábola que pasa por esos dos puntos. Pero existen infinitas parábolas que pasan por dos puntos dados. Una de ellas tiene f(0) = 42, pero otra tiene f(0) = 100, otra f(0) = 0, y otra f(0) = 999.999. Todas son igualmente compatibles con la información que poseen. No es que sea "muy difícil" adivinar el secreto: es que todos los valores posibles del secreto son exactamente igual de probables. Esto es lo que los criptógrafos llaman seguridad perfecta desde el punto de vista de la teoría de la información, el mismo nivel de seguridad que el cifrado de Vernam (el one-time pad), que es el único sistema criptográfico matemáticamente irrompible.

Campos finitos: por qué no usamos números normales

En el ejemplo anterior hemos usado números normales (enteros, fracciones) para que la explicación sea clara. En la práctica, esto tiene un problema grave: los números crecen sin control. Si el secreto es un número de 256 bits (como una clave criptográfica), los valores del polinomio pueden ser enormes, y las fracciones intermedias de Lagrange hacen los cálculos imprácticos. Además, trabajar con fracciones decimales introduce errores de redondeo.

La solución es usar campos finitos, también llamados cuerpos de Galois. Un campo finito es, en esencia, un sistema numérico que "se enrolla sobre sí mismo" al llegar a un cierto valor, como un reloj. En un reloj de 12 horas, después de las 11 viene las 12, y después de las 12 vuelve la 1. En un campo finito módulo p (donde p es un número primo), todos los cálculos se hacen "módulo p": si el resultado supera p, se toma el resto de dividir por p. Por ejemplo, en un campo módulo 7: 5 + 4 = 9, pero 9 mod 7 = 2, así que el resultado es 2.

Lo brillante de los campos finitos es que conservan todas las propiedades aritméticas que necesitamos —se puede sumar, restar, multiplicar y dividir— pero los números nunca crecen más allá de p. Cada share tiene exactamente el mismo tamaño que el secreto original, y no hay fracciones ni errores de redondeo. En la criptografía de umbral moderna, se utilizan primos enormes (de 256 bits o más), lo que significa que el "reloj" tiene más posiciones que átomos en el universo observable.

Feldman VSS: verificar que nadie nos ha engañado

El problema del repartidor deshonesto

El esquema de Shamir tiene una debilidad fundamental que no es matemática, sino humana. Imaginemos esta situación: Alicia es la persona encargada de generar el secreto y repartir los fragmentos entre cinco directivos de una empresa. Alicia construye su polinomio, calcula los cinco shares y los reparte. Pero Alicia tiene un plan: a uno de los directivos —Carlos, con quien tiene un conflicto— le entrega deliberadamente un fragmento falso. Un número que no corresponde a ningún punto del polinomio real.

Nadie se dará cuenta del engaño hasta el día en que necesiten reconstruir el secreto. Ese día, si Carlos participa en la reconstrucción, el resultado será incorrecto. Los otros participantes pensarán que el sistema ha fallado, o que Carlos es el saboteador, pero Carlos no tiene forma de demostrar que su fragmento es el que recibió originalmente ni que ese fragmento era ya falso desde el principio. Alicia ha conseguido sabotear el sistema de forma indetectable.

Este escenario no es puramente teórico. En cualquier sistema donde las partes no confían plenamente unas en otras —y en criptografía, la regla de oro es no confiar en nadie— necesitamos un mecanismo para que cada participante pueda verificar, en el momento de recibir su fragmento, que ese fragmento es auténtico y consistente con los de los demás. Esto es lo que se conoce como Verifiable Secret Sharing (VSS), o "compartición verificable de secretos".

La solución de Feldman: sellos públicos de verificación

En 1987, Paul Feldman propuso una solución elegante basada en una idea que, despojada de su formalismo matemático, funciona así: imagina que Alicia, antes de repartir los fragmentos, coloca unos "sellos" en un tablón público. Estos sellos están construidos de tal manera que cualquier persona puede usarlos para comprobar si su fragmento es consistente con el polinomio original, pero nadie puede deducir el secreto a partir de los sellos.

Técnicamente, Feldman utiliza un generador g de un grupo cíclico —un conjunto matemático en el que la exponenciación tiene la propiedad de ser fácil de calcular en una dirección pero prácticamente imposible de invertir—. Para cada coeficiente aₖ del polinomio, Alicia publica el valor Cₖ = g^aₖ. Estos valores Cₖ son los "sellos" o commitments.

Cuando el participante i recibe su fragmento sᵢ, puede verificarlo comprobando que:

g^sᵢ = C₀ · C₁^i · C₂^(i²) · ... · C_(t-1)^(i^(t-1))

Si la igualdad se cumple, el fragmento es auténtico. Si no, el participante sabe inmediatamente que alguien le ha enviado un fragmento falso y puede rechazarlo públicamente antes de que sea demasiado tarde. Es como si cada fragmento llevara un sello holográfico que solo puede verificarse contra el tablón público, pero que no revela el contenido del sobre.

Pedersen VSS: ocultando incluso los sellos

El esquema de Feldman tiene una limitación sutil: los commitments Cₖ = g^aₖ revelan cierta información sobre los coeficientes del polinomio. En particular, C₀ = g^a₀ = g^secreto. Aunque no es posible extraer el secreto directamente (por la dificultad del logaritmo discreto), esto podría permitir a un atacante comprobar candidatos: "¿Es el secreto 42? Veamos si g^42 = C₀". Si el espacio de posibles secretos es reducido, este ataque de fuerza bruta podría funcionar.

Torben Pedersen resolvió esto en 1991 con una variante que añade un segundo generador h y un polinomio aleatorio adicional. Los commitments de Pedersen tienen la forma Cₖ = g^aₖ · h^bₖ, donde bₖ es aleatorio. Estos commitments son perfectamente ocultadores: no revelan absolutamente ninguna información sobre los coeficientes, ni siquiera a un atacante con capacidad computacional ilimitada. Al mismo tiempo, siguen siendo computacionalmente vinculantes: el repartidor no puede cambiar los coeficientes después de publicar los commitments sin romper un problema matemático que se considera intratable.

Esta distinción entre Feldman y Pedersen puede parecer académica, pero es crucial en sistemas reales. En un protocolo de criptografía de umbral donde los commitments son públicos y permanentes (por ejemplo, registrados en una blockchain), la diferencia entre "revelar algo de información" y "no revelar nada" puede ser la diferencia entre un sistema seguro durante décadas y uno que se vuelve vulnerable a medida que la capacidad computacional de los atacantes crece.

Firmas de umbral BLS: firmar entre varios sin reconstruir la clave

¿Qué son los pairings bilineales? Una analogía desarrollada

Para entender las firmas BLS necesitamos hablar de un concepto llamado pairing bilineal. Aunque suena intimidante, la idea puede entenderse con una analogía cotidiana.

Imaginemos dos salas de un museo, cada una con su propia colección de esculturas. La Sala A tiene esculturas de bronce y la Sala B tiene esculturas de mármol. Existe una tercera sala —la Sala C— que contiene mosaicos. El museo posee una operación matemática que hace lo siguiente: introduces una escultura de bronce de la Sala A y una escultura de mármol de la Sala B, y la máquina produce un mosaico específico de la Sala C. La máquina tiene una propiedad especial: si primero "modificas" la escultura de bronce de cierta manera (digamos, la amplías al doble) y luego la introduces con la misma escultura de mármol, el mosaico resultante es exactamente el mismo que si hubieras introducido la escultura de bronce original con la escultura de mármol "modificada" de la misma manera.

En términos matemáticos, un pairing bilineal es una función e que toma un elemento del grupo G₁ y un elemento del grupo G₂ y produce un elemento del grupo G_T. Su propiedad fundamental es: e(a·P, Q) = e(P, a·Q) = e(P, Q)^a. Esta propiedad de "mover factores entre los argumentos" es lo que permite verificar firmas sin conocer la clave privada, y es la base de todo lo que viene a continuación.

Concretamente, estos grupos no son colecciones de esculturas sino conjuntos de puntos que pertenecen a una curva elíptica. Una curva elíptica es una curva especial definida por una ecuación como y² = x³ + ax + b. Los puntos de esta curva, junto con una operación de "suma" geométrica, forman un grupo algebraico con propiedades idóneas para la criptografía: es fácil "multiplicar" un punto por un número (sumar el punto consigo mismo muchas veces), pero dado el resultado, es prácticamente imposible averiguar por qué número se multiplicó. Este es el problema del logaritmo discreto en curvas elípticas, y su dificultad es lo que mantiene seguros estos sistemas.

¿Por qué BLS12-381 específicamente?

No todas las curvas elípticas soportan pairings, y entre las que sí lo hacen, no todas ofrecen el mismo equilibrio entre seguridad y rendimiento. BLS12-381, diseñada por Sean Bowe en 2017, es posiblemente la mejor opción disponible hoy para la comunidad blockchain (se usa en Ethereum 2.0, Zcash, Filecoin y muchos otros proyectos). El nombre codifica sus parámetros: "BLS" por Barreto-Lynn-Scott (los diseñadores de la familia de curvas), "12" por el grado de embedding (un parámetro técnico que determina la eficiencia del pairing), y "381" por el número de bits del primo que define el campo base.

Esta curva ofrece aproximadamente 128 bits de seguridad, lo que significa que un atacante necesitaría realizar del orden de 2¹²⁸ operaciones para romperla, un número tan astronómico que supera la capacidad computacional combinada de toda la humanidad durante la edad del universo. Al mismo tiempo, las operaciones de pairing en BLS12-381 son lo suficientemente rápidas para ser prácticas en aplicaciones del mundo real.

Firmar con fragmentos: cómo funciona

Ahora podemos explicar las firmas de umbral BLS. El sistema funciona así: la clave privada sk se divide mediante Shamir's Secret Sharing entre n participantes, con un umbral t. Cada participante i recibe un fragmento de clave skᵢ. La clave pública correspondiente, pk = sk · G₂ (donde G₂ es el generador del segundo grupo), se publica abiertamente.

Cuando es necesario firmar un mensaje m, cada participante calcula su firma parcial: toma el hash del mensaje, lo convierte en un punto de la curva elíptica H(m), y lo multiplica por su fragmento de clave: σᵢ = skᵢ · H(m). Cada participante envía su firma parcial a un coordinador (o a los demás participantes).

Una vez recibidas al menos t firmas parciales, se combinan usando los coeficientes de Lagrange —la misma técnica que usamos antes para reconstruir el secreto, pero ahora aplicada a puntos de la curva elíptica en lugar de a números—. El resultado es la firma completa σ, que es matemáticamente idéntica a la que habría producido la clave privada original si alguien la hubiera tenido completa. Y aquí está lo extraordinario: la clave privada completa nunca ha existido en ningún lugar durante todo el proceso. Se generó distribuida y se usó distribuida.

La verificación es donde brilla el pairing bilineal. Cualquier persona que conozca la clave pública pk puede verificar la firma comprobando que e(σ, G₂) = e(H(m), pk). Si esta igualdad se cumple, la firma es válida. Si no, ha sido manipulada o fabricada. La firma de umbral es indistinguible de una firma normal: el verificador no puede saber si la firmó una sola persona o un comité de cincuenta.

Proof-of-Possession: defenderse del ataque del rogue key

Existe un ataque sutil pero devastador contra las firmas BLS que merece ser contado como historia. Imaginemos que tres personas —Ana, Bruno y Clara— configuran un sistema de multifirma BLS. Cada una genera su par de claves y publica su clave pública. La clave pública agregada del grupo es simplemente la suma de las tres claves públicas individuales: pk_grupo = pk_A + pk_B + pk_C.

Ahora imaginemos que Clara es maliciosa. Antes de publicar su clave pública, Clara espera a ver las claves de Ana y Bruno. Entonces, en lugar de generar una clave honesta, Clara calcula: pk_C' = sk_C · G₂ - pk_A - pk_B. Cuando se suman las tres claves públicas para formar la clave del grupo, las claves de Ana y Bruno se cancelan: pk_grupo = pk_A + pk_B + pk_C' = pk_A + pk_B + (sk_C · G₂ - pk_A - pk_B) = sk_C · G₂. La clave pública del grupo es ahora solo la clave de Clara. Ella puede firmar mensajes sola, sin la participación de Ana ni Bruno, y las firmas pasarán la verificación como si todo el grupo hubiera firmado.

La defensa contra este ataque es el Proof-of-Possession (PoP): cuando cada participante publica su clave pública, debe acompañarla de una firma sobre la propia clave pública. Esto demuestra que el participante conoce la clave privada correspondiente a la clave pública que anuncia. Clara no puede generar una PoP válida para su clave fraudulenta pk_C' porque no conoce la clave privada correspondiente (tendría que conocer sk_C - sk_A - sk_B, pero no conoce sk_A ni sk_B). Este mecanismo, aparentemente simple, cierra una vulnerabilidad que podría comprometer sistemas enteros.

VRF distribuido: aleatoriedad verificable que nadie puede manipular

La lotería nacional que nadie puede trucar

Imaginemos que el gobierno de un país decide modernizar su lotería nacional. La lotería tradicional usa bolas físicas en un bombo, un mecanismo que durante siglos ha sido razonablemente confiable, pero que no está exento de problemas: ha habido escándalos de bombos trucados, bolas con peso alterado, y directores de lotería que han sido sobornados. El gobierno quiere una lotería digital, completamente transparente, en la que cualquier ciudadano pueda verificar que el resultado es auténtico.

Pero una lotería digital presenta un dilema aparentemente irresoluble. Si un servidor central genera el número aleatorio, ¿cómo confían los ciudadanos en que no ha sido manipulado? Si el número se genera antes del cierre de apuestas y alguien lo descubre, puede apostar a ganador. Si se genera después, el operador podría elegir un número que beneficie a ciertos apostantes. Necesitamos un número que sea simultáneamente impredecible (nadie puede saberlo de antemano), insesgable (nadie puede influir en su valor) y verificable (cualquiera puede comprobar que se generó correctamente).

Esto es exactamente lo que proporciona una Función Aleatoria Verificable distribuida (dVRF, por distributed Verifiable Random Function). Un comité de, digamos, 100 operadores independientes —cada uno con su fragmento de clave— contribuye a la generación del número aleatorio. Cada operador calcula su contribución parcial a partir de una entrada pública conocida (por ejemplo, "Sorteo-2026-03-13-noche") y la envía. Cuando se recogen al menos 67 contribuciones (el umbral), se combinan para producir el número aleatorio final y una prueba criptográfica de que ese número se calculó correctamente.

Ningún operador individual —ni siquiera 66 operadores confabulados— puede predecir cuál será el resultado. Esto se debe a que el número final depende de las contribuciones de al menos 67 participantes, y hasta que no se recoge la contribución número 67, el resultado es completamente indeterminado. Además, una vez publicado el resultado, cualquier ciudadano puede verificar la prueba criptográfica usando solo la clave pública del comité, sin necesidad de confiar en ningún operador individual.

Las tres propiedades, explicadas

Impredecibilidad: antes de que el umbral de participantes haya contribuido, el resultado es computacionalmente indistinguible de un número verdaderamente aleatorio. No importa cuánta información posea un atacante sobre las contribuciones parciales ya emitidas: si tiene menos que el umbral, su capacidad de predecir el resultado no es mejor que la de lanzar una moneda al aire. Esto se demuestra formalmente mediante una reducción al problema del logaritmo discreto en la curva BLS12-381.

Insesgabilidad: una vez que un participante ha emitido su contribución, no puede retirarla ni modificarla. Y lo que es más importante: un participante malicioso que intente calcular varias contribuciones posibles para elegir la que produce un resultado favorable descubrirá que solo existe una contribución válida para cada entrada y cada fragmento de clave. No hay margen de maniobra. La función es determinista: la misma entrada con el mismo fragmento de clave produce siempre la misma contribución.

Verificabilidad: la prueba criptográfica que acompaña al resultado permite a cualquier observador —sin conocimiento técnico especial, usando solo software público— comprobar que el número se generó mediante el protocolo correcto con contribuciones legítimas. Si alguien publicara un resultado falso, la prueba no pasaría la verificación y el fraude sería inmediatamente detectable.

En la práctica, las dVRF se utilizan hoy en protocolos blockchain como Dfinity (Internet Computer), Chainlink VRF y drand (el servicio de aleatoriedad distribuida de Protocol Labs), proporcionando aleatoriedad verificable para contratos inteligentes, sorteos, selección de validadores y cualquier aplicación donde se necesite un número que nadie haya podido manipular.

Cifrado de datos a escala: el esquema híbrido

El problema: la criptografía de umbral es lenta

Imaginemos que queremos cifrar un archivo de vídeo de 4 gigabytes usando criptografía de umbral. Si intentáramos cifrar cada byte directamente con operaciones de curva elíptica, el proceso llevaría horas o días: las operaciones de curva elíptica son centenares de veces más lentas que los algoritmos de cifrado simétrico convencionales. Es como intentar transportar una mudanza completa en un coche deportivo: el coche es extraordinariamente seguro y rápido, pero solo cabe una caja cada vez.

La solución es un esquema híbrido, el mismo principio que usa WhatsApp, Signal o cualquier aplicación moderna de mensajería, aunque adaptado al contexto de la criptografía de umbral.

Cómo funciona, paso a paso

Piensa en cómo enviarías un paquete muy valioso por correo. No construirías una caja fuerte del tamaño del paquete (demasiado caro y pesado). En su lugar, meterías el paquete en una caja normal cerrada con un candado pequeño pero robusto, y luego enviarías la llave del candado dentro de una caja fuerte pequeña. El paquete viaja protegido por el candado (rápido, eficiente), y la llave viaja protegida por la caja fuerte (más lenta pero ultra-segura). Esto es exactamente un esquema híbrido.

En la práctica funciona así: se genera una clave de cifrado de datos (DEK, Data Encryption Key), un número aleatorio de 256 bits que se usa una sola vez. Con esta DEK se cifra el archivo completo usando un algoritmo simétrico ultrarrápido como XChaCha20-Poly1305. Este algoritmo puede procesar gigabytes por segundo en hardware moderno. La DEK —que son solo 32 bytes— se cifra a su vez con la clave pública del sistema de umbral. El resultado final es: el archivo cifrado (del mismo tamaño que el original, más o menos) y la DEK cifrada (unos pocos cientos de bytes).

Para descifrar, el proceso se invierte: primero, un umbral de participantes colabora para descifrar la DEK (una sola operación de criptografía de umbral, que tarda milisegundos). Luego, con la DEK ya disponible, se descifra el archivo completo a velocidad simétrica. La criptografía de umbral solo se aplica a 32 bytes, no a 4 gigabytes.

¿Por qué XChaCha20 y por qué un nonce largo?

Si tuviéramos que elegir un algoritmo para esta capa, nos decantaríamos por XChaCha20-Poly1305 por varias razones. Primero, es un algoritmo de flujo: cifra los datos byte a byte, sin necesidad de rellenar bloques, lo que lo hace eficiente para archivos de cualquier tamaño. Segundo, "Poly1305" es un código de autenticación que garantiza no solo la confidencialidad sino también la integridad: si alguien modifica un solo bit del archivo cifrado, el descifrado fallará en lugar de producir datos corruptos silenciosamente.

La "X" en XChaCha20 significa que usa un nonce extendido de 192 bits (24 bytes), frente a los 96 bits del ChaCha20 estándar. Un nonce es un número que se usa una sola vez para garantizar que cifrar el mismo mensaje dos veces produce resultados diferentes. Con un nonce de 192 bits, se pueden generar nonces aleatorios sin riesgo práctico de colisión: la probabilidad de generar dos nonces iguales por azar es tan baja que necesitarías cifrar más mensajes de los que podrían caber en todos los discos duros del planeta antes de preocuparte.

Chunking: dividir para conquistar

Cuando el archivo es muy grande —varios gigabytes—, cifrarlo como un único bloque monolítico presenta problemas prácticos. Si se corrompe un solo byte durante la transmisión, hay que descargar y descifrar todo el archivo de nuevo. Además, en dispositivos con memoria limitada, cargar un archivo entero en RAM no siempre es posible.

La solución es el chunking: dividir el archivo en fragmentos de tamaño fijo (por ejemplo, 64 kilobytes cada uno) y cifrar cada fragmento de forma independiente con la misma DEK pero un nonce diferente. Es como dividir un libro en capítulos y enviar cada capítulo en un sobre sellado. Si un sobre se daña, solo se reenvía ese capítulo, no el libro entero. Y cada capítulo puede descifrarse de forma independiente, lo que permite empezar a reproducir un vídeo antes de que se haya descargado completo (descifrado por streaming).

Cada fragmento incluye un índice secuencial autenticado, lo que impide que un atacante reordene, duplique o elimine fragmentos sin que el receptor lo detecte. El resultado es un sistema de cifrado que combina la robustez de la criptografía de umbral con la eficiencia y practicidad del cifrado simétrico moderno.

Comités dinámicos: rotación sin fragilidad

El consejo de administración que se renueva

Piensa en el consejo de administración de una gran empresa. Los consejeros cambian con el tiempo: algunos se jubilan, otros son destituidos, se incorporan nuevos miembros con perspectivas frescas. Sin embargo, la empresa —con sus contratos, sus activos, sus obligaciones— continúa sin interrupción. No se crea una empresa nueva cada vez que cambia el consejo; el poder de decisión se transfiere de forma ordenada.

Ahora imaginemos que el "poder de decisión" no es una metáfora legal, sino un secreto criptográfico: una clave privada que controla activos digitales por valor de cientos de millones de euros. ¿Cómo transferimos ese poder de un comité saliente a un comité entrante sin que la clave privada quede expuesta en ningún momento? ¿Sin que exista un instante de transición en el que alguien tenga acceso completo?

En un esquema ingenuo, podríamos pensar: "El comité saliente reconstruye la clave, se la entrega a un intermediario de confianza, y este genera nuevos fragmentos para el comité entrante". Pero esto viola el principio fundamental: la clave nunca debe existir reconstruida. En el instante en que alguien posee la clave completa, ese alguien es un punto único de fallo. Si es atacado, sobornado o comete un error en ese preciso momento, todo se pierde.

Resharing: el traspaso sin punto de contacto

La solución se llama resharing (o proactive secret sharing con cambio de comité), y funciona de una forma que al principio parece imposible. El comité saliente genera nuevos fragmentos para el comité entrante sin reconstruir jamás la clave original. Cada miembro del comité saliente toma su fragmento, lo "re-comparte" usando un nuevo polinomio de Shamir, y envía los sub-fragmentos resultantes a los miembros del comité entrante. Cada miembro del comité entrante recibe sub-fragmentos de varios miembros del comité saliente y los combina (usando interpolación de Lagrange) para obtener su nuevo fragmento definitivo.

Lo extraordinario es que los nuevos fragmentos corresponden a un polinomio completamente distinto del original, pero que tiene el mismo valor en x = 0: el secreto. Los fragmentos antiguos quedan obsoletos. Un atacante que hubiera comprometido dos fragmentos del comité antiguo no tiene ventaja alguna sobre los fragmentos del comité nuevo, porque pertenecen a polinomios matemáticamente independientes.

Este mecanismo permite que un sistema de criptografía de umbral funcione indefinidamente, adaptándose a cambios organizativos, rotación de personal, actualización de hardware o expansión geográfica, todo ello sin que la clave subyacente cambie (y, por tanto, sin que cambien las direcciones, certificados o identidades criptográficas asociadas a ella). Es el equivalente digital de una institución que perdura a través de generaciones de personas.

Proactive refresh: derrotar al atacante paciente

La historia del atacante que colecciona fragmentos

Elena es una adversaria sofisticada y paciente. Su objetivo es robar la clave privada de un sistema de umbral configurado con 5 participantes y umbral 3. Sabe que necesita al menos 3 fragmentos para reconstruir la clave, pero también sabe que no necesita obtener los tres al mismo tiempo. Su plan es a largo plazo.

En enero, Elena consigue infiltrarse brevemente en el servidor de la participante 1 y copia su fragmento. Luego borra sus huellas y se retira. El equipo de seguridad revisa los sistemas, no detecta nada inusual, y la vida sigue. En junio, mediante un sofisticado ataque de phishing, Elena obtiene el fragmento de la participante 4. De nuevo se retira sin ser detectada. Ahora tiene 2 de los 3 fragmentos necesarios. Solo necesita una brecha más —en cualquier momento del futuro— y habrá ganado.

Este escenario ilustra una debilidad del sistema de Shamir tal como lo hemos descrito: los fragmentos son estáticos. Una vez repartidos, no cambian nunca. Un atacante que comprometió un fragmento hace cinco años sigue teniendo un fragmento válido hoy. Puede acumular fragmentos a lo largo del tiempo, a su propio ritmo, y combinarlos cuando tenga suficientes. Es el ataque del ladrón paciente.

El mecanismo de refresco: matar los fragmentos viejos

El proactive refresh (refresco proactivo) es la contramedida. Periódicamente —digamos cada semana, cada día o cada hora—, los participantes ejecutan un protocolo de refresco que reemplaza todos los fragmentos por otros nuevos, sin cambiar el secreto subyacente.

El mecanismo es sorprendentemente elegante. Cada participante i genera un polinomio aleatorio rᵢ(x) de grado t-1 con la condición de que rᵢ(0) = 0 (su término independiente es cero). Luego envía rᵢ(j) a cada otro participante j. Cada participante suma todos los valores de refresco que recibe a su fragmento actual: sⱼ_nuevo = sⱼ_viejo + r₁(j) + r₂(j) + ... + rₙ(j).

¿Por qué funciona? Porque el nuevo polinomio subyacente es f_nuevo(x) = f_viejo(x) + r₁(x) + r₂(x) + ... + rₙ(x). Y el secreto —el valor en x = 0— no cambia, porque todos los polinomios de refresco tienen valor 0 en x = 0: f_nuevo(0) = f_viejo(0) + 0 + 0 + ... + 0 = secreto.

Después del refresco, los fragmentos antiguos se destruyen. Ahora, los 2 fragmentos que Elena robó en enero y junio pertenecen a un polinomio que ya no existe. Son inútiles. No pueden combinarse con fragmentos nuevos porque pertenecen a polinomios diferentes. Elena tendría que obtener 3 fragmentos dentro del mismo período de refresco, lo que reduce drásticamente la ventana de oportunidad del atacante. Si el refresco se ejecuta cada hora, Elena tiene 60 minutos para comprometer 3 participantes independientes. Si se ejecuta cada minuto, tiene 60 segundos. La seguridad ya no es estática: es un objetivo móvil.

Tolerancia a fallos bizantinos: el problema de los generales

La historia completa

En 1982, los informáticos Leslie Lamport, Robert Shostak y Marshall Pease publicaron un artículo que se ha convertido en uno de los más citados de la historia de la computación. En él, plantearon el siguiente escenario:

Un ejército bizantino rodea una ciudad enemiga. El ejército está dividido en varios destacamentos, cada uno dirigido por un general. Los generales solo pueden comunicarse entre sí mediante mensajeros que cabalgan de un campamento a otro. Para que el asedio tenga éxito, todos los generales leales deben ejecutar el mismo plan: o todos atacan a la vez, o todos se retiran. Un ataque parcial —en el que algunos atacan y otros se retiran— sería desastroso y conduciría a la derrota.

El problema es que algunos generales pueden ser traidores. Un general traidor puede enviar mensajes contradictorios: decirle a unos que atacará y a otros que se retirará, con el objetivo de provocar una acción descoordinada. Peor aún, un traidor puede falsificar mensajes supuestamente de otros generales. Los generales leales deben encontrar un protocolo que les permita ponerse de acuerdo a pesar de la presencia de traidores, sin saber de antemano quiénes son los traidores.

Supongamos que hay 4 generales: Alejandro, Boudica, César y Diana. Alejandro es el comandante en jefe y envía la orden "atacar" a los otros tres. Pero Diana es traidora. Diana le dice a Boudica: "Alejandro me ha dicho que nos retiremos" (una mentira). Si Boudica no tiene forma de verificar qué dijo realmente Alejandro, está en un dilema: ¿ataco, como dice el mensaje de Alejandro, o me retiro, como sugiere Diana? Si Boudica toma la decisión equivocada, el ejército se divide.

Ahora imaginemos algo aún peor: ¿y si el propio Alejandro es el traidor? Alejandro podría enviar "atacar" a Boudica y César, pero "retirada" a Diana. Los tres subordinados no saben que han recibido órdenes diferentes y podrían actuar de forma descoordinada.

¿Por qué exactamente un tercio?

Lamport, Shostak y Pease demostraron un resultado sorprendente: si hay f generales traidores, el protocolo solo funciona si el número total de generales n cumple n ≥ 3f + 1. Es decir, el sistema tolera como máximo un tercio de traidores (menos uno). Con 4 generales, se tolera 1 traidor. Con 7, se toleran 2. Con 10, se toleran 3.

¿Por qué un tercio y no la mitad? La intuición es la siguiente: cuando un general leal recibe mensajes contradictorios, necesita "preguntar" a los demás qué han oído ellos. Si hay demasiados traidores, sus respuestas falsas pueden "ahogar" las respuestas honestas. Con menos de un tercio de traidores, los generales leales siempre son mayoría suficiente para que la verdad prevalezca en las votaciones internas del protocolo. Con un tercio o más, los traidores pueden crear una situación simétrica en la que los generales leales no pueden distinguir entre dos escenarios contradictorios.

Otra forma de verlo: un general leal necesita dos "testigos" independientes para cada mensaje que verifica (uno para confirmar y otro para romper un posible empate). Si un tercio de los participantes son deshonestos, ya no hay suficientes testigos honestos disponibles para este proceso de verificación cruzada.

Aplicación a la criptografía de umbral

En un sistema de criptografía de umbral, los participantes se enfrentan a una versión del problema de los generales bizantinos. Un participante malicioso puede enviar firmas parciales incorrectas, compartir fragmentos de refresco adulterados, o simplemente negarse a participar. El sistema debe funcionar correctamente —producir firmas válidas, descifrar datos, generar aleatoriedad— a pesar de la presencia de estos participantes maliciosos.

Por ello, los protocolos de umbral modernos se diseñan con la relación n ≥ 3t - 1 en mente (donde t es el umbral y n el número total de participantes). Un sistema con 10 participantes y umbral 4 puede tolerar hasta 3 participantes que sean activamente maliciosos (envíen datos falsos) y varios más que simplemente estén desconectados (fallos por caída), manteniendo en todo momento la capacidad de generar firmas y descifrar datos correctamente.

Casos de uso: historias del mundo real

Custodia de activos digitales: el banco del siglo XXI

María dirige una empresa de gestión patrimonial en Madrid que administra carteras de criptomonedas para clientes institucionales: fondos de pensiones, family offices y empresas tecnológicas. Sus clientes le confían activos por valor de 200 millones de euros en Bitcoin, Ethereum y otros activos digitales. La pesadilla de María es sencilla de describir: si pierde las claves privadas, pierde los activos de sus clientes de forma irrecuperable. No hay banco central que emita nuevos bitcoins para reemplazar los perdidos, no hay seguro que cubra la pérdida total de claves criptográficas.

María implementa un sistema de criptografía de umbral con la siguiente configuración: 7 fragmentos de clave repartidos entre 7 dispositivos de seguridad (Hardware Security Modules, HSM) ubicados en centros de datos de tres países diferentes —España, Suiza y Singapur—, con un umbral de 5. Para autorizar cualquier transacción, se necesitan al menos 5 de los 7 dispositivos. Esto significa que incluso si un centro de datos es destruido por un desastre natural (perdiendo hasta 2 dispositivos) o si un empleado desleal compromete un HSM, el sistema sigue operativo y seguro.

Cada semana, los dispositivos ejecutan automáticamente un protocolo de refresco proactivo, reemplazando todos los fragmentos sin cambiar las direcciones criptográficas de los clientes. Si un atacante hubiera copiado un fragmento el lunes, ese fragmento es inútil el lunes siguiente. La ventana de vulnerabilidad se reduce de "para siempre" a "siete días". Además, cada trimestre se realiza un resharing hacia un nuevo conjunto de dispositivos, permitiendo que María actualice el hardware sin interrumpir el servicio.

Firma corporativa: contratos que requieren consenso

Javier es director financiero de una constructora que ejecuta proyectos de infraestructura pública. La empresa firma contratos por decenas de millones de euros, y la firma digital de estos contratos tiene la misma validez legal que una firma manuscrita según el Reglamento eIDAS de la Unión Europea. El problema de Javier es que el CEO, el director financiero y el director jurídico deben aprobar cualquier contrato que supere los 5 millones de euros, pero rara vez están los tres en la misma ciudad al mismo tiempo.

Con un sistema tradicional, la solución sería que cada directivo tuviera su propio certificado digital y firmara secuencialmente. Pero esto genera tres firmas independientes, complica la verificación por parte de la Administración Pública y no refleja la realidad corporativa: lo que se quiere expresar no es "tres personas han firmado" sino "la empresa, actuando a través de su órgano de gobierno, ha firmado". La firma de umbral BLS permite exactamente esto: los tres directivos firman con sus fragmentos de clave desde Madrid, Londres y Tokio, y las firmas parciales se combinan en una única firma corporativa que es indistinguible de la firma de una sola entidad.

El sistema se configura con un umbral de 2 de 3, lo que significa que si uno de los tres directivos está en un vuelo transoceánico o de vacaciones, los otros dos pueden firmar sin retrasar la operación. Si un directivo deja la empresa, se ejecuta un resharing hacia un nuevo comité de tres, y los fragmentos del directivo saliente quedan automáticamente invalidados. No es necesario revocar certificados, generar nuevas claves ni notificar a las contrapartes. La identidad criptográfica de la empresa permanece inalterada.

Cumplimiento GDPR: cifrado con supervisión distribuida

Elena es la delegada de protección de datos de un hospital universitario que trata a 500.000 pacientes al año. El Reglamento General de Protección de Datos (GDPR) de la Unión Europea exige que los datos médicos personales se protejan con las medidas técnicas más avanzadas disponibles, y que el acceso a estos datos esté estrictamente controlado y auditable. Al mismo tiempo, los médicos necesitan acceso rápido a los historiales clínicos en situaciones de emergencia.

Elena diseña un sistema en el que todos los historiales clínicos se cifran con un esquema híbrido de criptografía de umbral. La clave de descifrado está dividida entre cinco fragmentos: dos en poder del departamento de sistemas del hospital, uno en poder del comité ético, uno en un servicio de custodia externo certificado, y uno en la oficina del delegado de protección de datos. El umbral es 3: para descifrar cualquier historial, se necesita la colaboración de al menos tres de estos cinco custodios.

En la práctica diaria, el proceso es transparente para los médicos: cuando un doctor autorizado solicita un historial, el sistema de gestión envía automáticamente la solicitud a los custodios, que la aprueban (o la rechazan) en función de reglas predefinidas. Para accesos rutinarios de médicos autorizados, la aprobación es automática y tarda milisegundos. Pero si alguien intenta acceder a un historial sin autorización —o si un administrador de sistemas intenta acceder a datos clínicos—, el sistema exige aprobación manual del comité ético, generando un registro de auditoría inmutable. En caso de una inspección de la Agencia Española de Protección de Datos, Elena puede demostrar que ningún individuo tiene capacidad unilateral de acceder a los datos de los pacientes, cumpliendo así con los principios de minimización y seguridad que exige el GDPR.

Finalidad en blockchain: el consenso que no se revierte

Pablo es ingeniero de protocolo en una red blockchain de prueba de participación (proof of stake). En estas redes, los validadores —nodos que verifican transacciones y proponen bloques— deben ponerse de acuerdo sobre qué bloques son válidos. Un problema recurrente es la finalidad: ¿en qué momento puede considerarse que una transacción es irreversible?

En Bitcoin, la respuesta es probabilística: después de 6 confirmaciones (unos 60 minutos), la probabilidad de reversión es extremadamente baja, pero nunca exactamente cero. Para una transferencia de 10 euros, esto es aceptable. Para la liquidación de un bono por 100 millones de euros entre dos bancos centrales, "extremadamente baja" no es suficiente. Necesitan certeza matemática.

Las firmas de umbral BLS proporcionan esta certeza. En la red de Pablo, cada época (un período de 6 minutos) culmina con una votación de finalidad: cada validador emite una firma parcial BLS sobre el bloque que considera canónico. Cuando se recogen firmas parciales de al menos dos tercios de los validadores (el umbral), se combinan en una firma de umbral que certifica la finalidad del bloque. Esta firma ocupa solo 48 bytes —independientemente de que hayan firmado 100 o 100.000 validadores— y puede verificarse con una sola operación de pairing, lo que la hace extraordinariamente eficiente.

Una vez que un bloque tiene su firma de finalidad, es matemáticamente irreversible: revertirlo requeriría que más de un tercio de los validadores fueran deshonestos, lo que activaría las penalizaciones económicas (slashing) del protocolo, destruyendo los depósitos de los atacantes. La combinación de criptografía de umbral y teoría de juegos crea un sistema donde la deshonestidad es no solo detectable, sino económicamente devastadora para quien la intente.

Para saber más

A continuación se recopilan los trabajos académicos y técnicos fundamentales para profundizar en cada aspecto de la criptografía de umbral. Cada referencia incluye una breve descripción de su aportación.

• Shamir, A. (1979). "How to Share a Secret". Communications of the ACM, 22(11), 612-613. El artículo fundacional de apenas dos páginas que introdujo el concepto de compartición de secretos basada en polinomios. Pese a su brevedad, estableció las bases de todo un campo de investigación.
• Feldman, P. (1987). "A Practical Scheme for Non-interactive Verifiable Secret Sharing". 28th IEEE Symposium on Foundations of Computer Science. Resuelve el problema de la verificabilidad: cómo garantizar que los fragmentos repartidos son consistentes sin revelar el secreto. Introduce los commitments basados en el logaritmo discreto.
• Pedersen, T. P. (1991). "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing". CRYPTO '91. Mejora el esquema de Feldman proporcionando commitments perfectamente ocultadores, lo que garantiza que ni siquiera un atacante con capacidad computacional ilimitada puede extraer información de los commitments públicos.
• Boneh, D., Lynn, B. y Shacham, H. (2001). "Short Signatures from the Weil Pairing". ASIACRYPT 2001. El artículo que introdujo las firmas BLS, demostrando que los pairings bilineales permiten firmas extraordinariamente compactas. Estas firmas son la base del esquema de umbral que utilizan la mayoría de las blockchains modernas.
• Herzberg, A., Jarecki, S., Krawczyk, H. y Yung, M. (1995). "Proactive Secret Sharing, or: How to Cope with Perpetual Leakage". CRYPTO '95. Introduce el concepto de refresco proactivo: renovar los fragmentos periódicamente para frustrar a atacantes que acumulan fragmentos comprometidos a lo largo del tiempo.
• Lamport, L., Shostak, R. y Pease, M. (1982). "The Byzantine Generals Problem". ACM Transactions on Programming Languages and Systems, 4(3), 382-401. La formulación original del problema de tolerancia a fallos bizantinos, con la demostración de que se necesitan al menos 3f + 1 participantes para tolerar f traidores.
• Gennaro, R., Jarecki, S., Krawczyk, H. y Rabin, T. (2007). "Secure Distributed Key Generation for Discrete-Log Based Cryptosystems". Journal of Cryptology, 20(1), 51-83. Describe cómo generar una clave distribuida entre múltiples partes sin que ninguna entidad centralizada conozca jamás la clave completa. Es el protocolo de generación distribuida de claves (DKG) más ampliamente implementado.
• Bowe, S. (2017). "BLS12-381: New zk-SNARK Elliptic Curve Construction". Especificación técnica de la curva BLS12-381, que se ha convertido en el estándar de facto para pairings en sistemas blockchain. Detalla los parámetros, las propiedades de seguridad y las optimizaciones de implementación.
• Galindo, D. y Hasuo, I. (2021). "Threshold Encryption in the Age of Blockchains". Una revisión moderna que contextualiza las técnicas clásicas de criptografía de umbral en el ecosistema blockchain actual, incluyendo aplicaciones a MEV (Maximal Extractable Value), ordenación justa de transacciones y votación on-chain.

La criptografía de umbral no es una tecnología futurista: es la infraestructura que ya sostiene sistemas que gestionan miles de millones de euros. Su principio rector —que ningún individuo debería tener el poder de comprometer un sistema entero— es tan antiguo como la democracia y tan actual como el último bloque validado en Ethereum.