Proxy Re-Encryption: compartir datos cifrados sin compartir claves

Cómo compartir datos cifrados sin perder el control: el reto del acceso delegado

Vivimos rodeados de cerraduras invisibles. Cada vez que envías un mensaje por WhatsApp, cada vez que tu banco procesa una transferencia, cada vez que almacenas un documento en la nube, hay un mecanismo de cifrado trabajando en silencio para que solo las personas autorizadas puedan leer esa información. El cifrado convierte tus datos legibles —una foto, un contrato, un historial médico— en una secuencia de caracteres absolutamente incomprensible para cualquiera que no posea la clave correcta. Hasta aquí, todo funciona.

El problema aparece en el momento en que necesitas compartir esos datos cifrados con otra persona. Y no es un problema menor ni un caso extremo: es algo que ocurre constantemente en la vida real. Un paciente que cambia de médico y necesita que el nuevo especialista acceda a sus radiografías. Una empresa que contrata una auditoría externa y debe compartir documentos financieros confidenciales. Un abogado que trabaja con un perito judicial y necesita darle acceso a determinadas pruebas sin exponerle el resto del expediente. En todos estos casos, la persona que posee los datos cifrados se enfrenta a un dilema que, con las herramientas tradicionales, no tiene una solución satisfactoria.

La primera opción —la más obvia y la más peligrosa— es compartir directamente la clave de descifrado. Es el equivalente digital de hacer una copia de la llave de tu casa y dársela a alguien. Una vez que la otra persona tiene tu clave, puede acceder a todos tus datos, no solo a los que querías compartir. Puede copiar la clave y pasársela a terceros. Y si esa clave se filtra o se la roban, tus datos quedan expuestos de forma permanente e irrevocable. No puedes «des-compartir» una clave que ya está en manos de otro.

La segunda opción es el proceso manual: descargas los datos cifrados, los descifras en tu ordenador, los vuelves a cifrar con la clave pública del destinatario y se los envías. Funciona, pero tiene problemas graves. Primero, requiere que tú estés disponible y actúes como intermediario cada vez que alguien necesite acceso, lo que no escala cuando tienes decenas de destinatarios o miles de documentos. Segundo, y más importante: durante el proceso de descifrado y re-cifrado, los datos existen en claro en la memoria de tu ordenador. Es una ventana de vulnerabilidad real. Si tu máquina está comprometida por malware, si alguien está monitorizando tu memoria, o si simplemente se produce un volcado de memoria por un error del sistema, esos datos quedan expuestos.

La tercera opción es delegar el trabajo a un servidor intermedio: «tú descifra y re-cifra por mí». Muchos servicios en la nube funcionan así. Pero esto significa que el servidor ve tus datos en claro durante el proceso. Has trasladado el problema de confianza, no lo has eliminado. Si ese servidor es hackeado, si la empresa que lo gestiona recibe un requerimiento judicial, si un empleado con acceso privilegiado decide curiosear, tus datos están ahí, legibles, esperando a ser leídos.

Proxy Re-Encryption resuelve este trilema. Permite que un intermediario transforme datos cifrados para una persona en datos cifrados para otra persona diferente, sin que ese intermediario pueda leer el contenido en ningún momento del proceso. El intermediario manipula datos que nunca puede descifrar. Es matemáticamente imposible que lo haga, no una cuestión de confianza o de política de privacidad: es una imposibilidad computacional.

Para entender cómo es posible algo así —que parece, a primera vista, un truco de magia—, necesitamos explorar la matemática que lo sustenta. No te preocupes: vamos a construir la explicación desde cero, paso a paso, con analogías que hacen tangible cada concepto antes de abordar el detalle técnico.

Criptografía de curva elíptica: la matemática detrás del cifrado moderno

La analogía de la pintura: por qué algunas operaciones no se pueden deshacer

Imagina que estás en un taller de pintura. Tienes delante dos botes: uno de pintura azul puro y otro de pintura amarilla pura. Si viertes ambos en un cubo y los mezclas, obtienes un verde brillante y uniforme. Cualquiera que vea el resultado —ese verde— puede verificar que es verde. Pero nadie en el mundo, por mucho tiempo, equipamiento o recursos que tenga, puede separar esa mezcla para recuperar el azul y el amarillo originales. La mezcla es irreversible.

Ahora imagina algo más sofisticado. Tú mezclas azul con amarillo y obtienes verde. Tu colega, de forma independiente, mezcla rojo con amarillo y obtiene naranja. Si ahora tú tomas el naranja de tu colega y le añades tu azul secreto, y tu colega toma tu verde y le añade su rojo secreto, ambos obtenéis exactamente el mismo color final. Os habéis puesto de acuerdo en un color compartido sin que ningún observador —que solo ha visto los colores intermedios— pueda deducir cuál es ese color final.

Esto es, en esencia, lo que hace la criptografía de curva elíptica. No trabaja con pintura, por supuesto, sino con puntos sobre curvas matemáticas. Pero el principio es el mismo: operaciones fáciles de hacer en una dirección, imposibles de revertir. Y la capacidad de que dos personas lleguen a un secreto compartido sin que nadie que observe el intercambio pueda deducirlo.

¿Qué es exactamente una curva elíptica?

Una curva elíptica es, en su forma más básica, el conjunto de puntos (x, y) que satisfacen una ecuación del tipo y² = x³ + ax + b. Si dibujas esta ecuación en un plano, obtienes una curva suave y simétrica respecto al eje horizontal. Pero lo que la hace extraordinaria para la criptografía no es su forma visual, sino una propiedad algebraica: se puede definir una operación de «suma» entre puntos de la curva. Si tomas dos puntos cualesquiera sobre la curva, puedes «sumarlos» siguiendo una regla geométrica precisa y obtener un tercer punto que también está sobre la curva.

En el plano real, esta suma funciona así: trazas una línea recta que pase por los dos puntos. Esa línea intersecará la curva en un tercer punto. Reflejas ese tercer punto respecto al eje horizontal, y el resultado es la «suma» de los dos puntos originales. Aunque suene abstracto, esta operación tiene todas las propiedades algebraicas que necesitamos: es asociativa (el orden de agrupación no importa), es conmutativa (el orden de los sumandos no importa), existe un elemento neutro (un «punto en el infinito» que actúa como el cero) y cada punto tiene un inverso. En terminología matemática, los puntos de la curva forman un grupo abeliano.

En la práctica criptográfica, no trabajamos sobre los números reales —que son infinitos y continuos—, sino sobre un campo finito. Esto significa que todos los cálculos se realizan «módulo un número primo grande»: los resultados se dividen por ese primo y nos quedamos con el resto. Esto convierte la curva, que sobre los reales es una línea continua, en un conjunto discreto y finito de puntos. Un conjunto grande —típicamente del orden de 2²⁵⁶ puntos—, pero finito y manejable por un ordenador.

¿Por qué Curve25519 y qué es Ristretto?

No todas las curvas elípticas son iguales. Algunas son más rápidas de calcular, otras ofrecen más seguridad, y algunas tienen propiedades sutiles que pueden provocar vulnerabilidades si el programador no las conoce. Curve25519, diseñada por el criptógrafo Daniel J. Bernstein en 2005. Si tuviéramos que elegir una curva para construir un sistema PRE, esta sería nuestra candidata, porque fue creada específicamente para ser difícil de implementar mal. Su estructura matemática —es una curva de Montgomery, una familia particular de curvas con propiedades aritméticas muy convenientes— permite operaciones extremadamente rápidas. Y ofrece aproximadamente 128 bits de seguridad, lo que significa que un atacante necesitaría realizar del orden de 2¹²⁸ operaciones (un número con 38 ceros) para romperla. Para poner esto en perspectiva: si todos los ordenadores del planeta trabajaran juntos en esta tarea, necesitarían más tiempo del que lleva existiendo el universo.

Ristretto es una capa adicional que resuelve un problema técnico sutil pero importante. Curve25519 tiene lo que se llama un «cofactor» de 8, lo que en la práctica significa que algunos puntos de la curva pueden tener varias representaciones diferentes en bytes. Dos secuencias de bytes distintas pueden representar el «mismo» punto. Esto no parece grave, pero en criptografía, donde la igualdad y la unicidad son fundamentales, puede provocar ataques sutiles. Ristretto define una codificación canónica —una forma única y estándar de representar cada punto— que elimina completamente esta ambigüedad. Cada punto tiene exactamente una representación, y las pruebas criptográficas que dependen de la igualdad de puntos funcionan de forma fiable.

La operación que lo sostiene todo: multiplicación escalar

Todo el edificio de la criptografía de curva elíptica descansa sobre una operación que se puede expresar en una sola línea:

clave_privada · G = clave_pública

Aquí, G es un punto fijo y público de la curva, conocido como punto generador: todo el mundo lo conoce, está publicado en el estándar de la curva. La clave_privada es un número entero grande y secreto, elegido al azar. Y la operación «clave_privada · G» significa «sumar el punto G consigo mismo tantas veces como indique la clave privada». Si tu clave privada es 7, calculas G + G + G + G + G + G + G. Si es un número de 256 bits, sumas G consigo mismo un número astronómico de veces.

Obviamente, nadie suma punto por punto cuando la clave privada es un número con 77 dígitos. Existen algoritmos eficientes como double-and-add (duplicar y sumar) que permiten calcular el resultado en un número de pasos proporcional al número de bits de la clave, no a su valor. Así, una multiplicación con una clave de 256 bits requiere como máximo 256 duplicaciones y 256 sumas: una fracción de milisegundo en cualquier ordenador moderno.

La seguridad del sistema se basa en que la operación inversa —dado el resultado (la clave pública) y el punto generador G, encontrar cuántas veces se sumó G para llegar a ese resultado— es el Problema del Logaritmo Discreto en Curvas Elípticas (conocido por sus siglas en inglés como ECDLP). Los mejores algoritmos conocidos para resolver este problema, como el algoritmo rho de Pollard, requieren del orden de 2¹²⁸ operaciones para curvas de 256 bits. Es una asimetría colosal: calcular la clave pública a partir de la privada tarda microsegundos; recuperar la clave privada a partir de la pública requiere más energía de la que podría producir una civilización galáctica.

Esta asimetría —fácil en una dirección, imposible en la otra— es el cimiento sobre el que se construye todo el sistema de Proxy Re-Encryption.

Las cápsulas: contenedores criptográficos inteligentes

La analogía del sobre con doble lacre

Imagina un sobre muy especial, fabricado con una tecnología que no existe en el mundo físico pero que resulta perfecta como metáfora. Este sobre tiene dos sellos de lacre, cada uno creado con un molde diferente. Los sellos no solo cierran el sobre: están fundidos con el papel de tal forma que cualquier intento de abrirlo, manipularlo o sustituir uno de los sellos destruiría automáticamente el contenido. Lo extraordinario de este sobre es que un intermediario especialmente autorizado puede, mediante un procedimiento mecánico preciso, transformar los sellos para que se correspondan con los moldes de otra persona, sin romperlos, sin ver el contenido y sin entender siquiera cómo funciona el proceso. El intermediario sigue instrucciones cifradas; ejecuta un procedimiento que produce un resultado correcto sin que él pueda verificar ni comprender qué está haciendo. Cuando el nuevo destinatario recibe el sobre, sus moldes encajan perfectamente con los sellos transformados, y el sobre se abre sin problemas.

En el sistema de Proxy Re-Encryption, la cápsula es la estructura de datos que hace posible esta transformación. Cuando Alice quiere cifrar un mensaje —ya sea un documento, una imagen, un historial médico o cualquier otro dato—, el sistema no cifra el mensaje directamente con su clave pública. En su lugar, genera una cápsula que contiene la información necesaria para derivar la clave de cifrado, pero codificada de tal manera que solo Alice (o alguien a quien Alice autorice explícitamente) puede extraer esa clave.

Paso 1: Generación de puntos efímeros

El primer paso es generar dos números aleatorios secretos, llamados r y u. «Efímeros» significa que se usan una sola vez y se destruyen inmediatamente después. Con estos números se calculan dos puntos de la curva elíptica:

• E = r · G (el punto efímero principal)
• V = u · G (el punto efímero de verificación)

¿Por qué dos puntos y no uno? Porque la estructura de dos puntos permite, más adelante, generar pruebas matemáticas de que la transformación (el re-cifrado) se ha realizado correctamente. El punto V actúa como un «testigo» criptográfico que permite verificar la integridad de todo el proceso. Además, el uso de valores efímeros garantiza que cada cifrado produce una cápsula completamente diferente, incluso si Alice cifra el mismo mensaje dos veces seguidas. Esto se conoce como seguridad semántica: un atacante que observe múltiples cifrados del mismo mensaje no puede deducir que el contenido es idéntico.

Paso 2: Derivación de la clave simétrica mediante ECDH

Aquí entra en juego el protocolo Elliptic Curve Diffie-Hellman, conocido como ECDH. Este protocolo, inventado originalmente por Whitfield Diffie y Martin Hellman en 1976 (en su versión para números enteros) y adaptado después a curvas elípticas, permite que dos partes lleguen a un secreto compartido sin transmitirlo nunca. En nuestro caso, el secreto compartido se calcula así:

punto_secreto = (r + u) · pk_Alice

Donde pk_Alice es la clave pública de Alice. Este punto de la curva se pasa por una función de derivación de clave (KDF, por Key Derivation Function), que lo transforma en una clave simétrica de 256 bits apta para cifrar datos. Una KDF toma una entrada de longitud variable —en este caso, las coordenadas de un punto de la curva— y produce una salida de longitud fija con apariencia aleatoria. Incluso si dos entradas son muy similares (difieren en un solo bit), las salidas son completamente diferentes. Esto garantiza que la clave simétrica resultante sea indistinguible del azar.

Lo elegante del esquema es que Alice, por su parte, puede llegar al mismo punto secreto usando su clave privada: sk_Alice · (E + V) = sk_Alice · (r · G + u · G) = sk_Alice · (r + u) · G = (r + u) · sk_Alice · G = (r + u) · pk_Alice. Ambas rutas llegan al mismo punto. Pero nadie más puede calcularlo: se necesita conocer o bien los efímeros r y u (que se destruyeron) o bien la clave privada de Alice sk_Alice (que solo ella conoce).

Paso 3: Cifrado autenticado con XChaCha20-Poly1305

Con la clave simétrica en mano, se cifra el mensaje real. A la hora de elegir el algoritmo de cifrado, no vale cualquiera: usa XChaCha20-Poly1305, un algoritmo de cifrado autenticado. Merece la pena detenerse en lo que significa «autenticado», porque es un concepto crucial que a menudo se pasa por alto.

Un algoritmo de cifrado «normal» (no autenticado) solo garantiza confidencialidad: convierte los datos en algo ilegible. Pero no garantiza integridad. Un atacante que no puede leer los datos cifrados podría, sin embargo, modificarlos a ciegas. Podría cambiar bits del texto cifrado, y cuando el destinatario lo descifre, obtendría un mensaje corrupto o —peor aún— un mensaje modificado de forma controlada por el atacante. Esto no es una especulación teórica: ataques como el bit-flipping contra CBC (un modo de cifrado clásico) han sido explotados en la práctica para manipular datos cifrados sin conocer la clave.

El cifrado autenticado resuelve esto añadiendo un código de autenticación de mensaje (MAC) que actúa como un sello de integridad. Si alguien modifica aunque sea un solo bit del texto cifrado, el MAC no coincidirá y el descifrado fallará de forma explícita. No obtendrás un mensaje corrupto: obtendrás un error claro que dice «estos datos han sido manipulados».

Si tuviéramos que elegir entre XChaCha20 y AES-GCM (que es probablemente el algoritmo de cifrado autenticado más utilizado en el mundo), nos decantaríamos por XChaCha20. Hay varias razones técnicas. La más importante es el tamaño del nonce (un valor aleatorio que se usa una sola vez por cada operación de cifrado). AES-GCM usa un nonce de 96 bits, lo que significa que si cifras más de aproximadamente 2³² mensajes con la misma clave, hay una probabilidad significativa de que dos nonces coincidan por azar. Y una colisión de nonces en AES-GCM es catastrófica: destruye por completo la seguridad. XChaCha20 usa un nonce de 192 bits, lo que hace las colisiones estadísticamente imposibles incluso generando nonces de forma completamente aleatoria. Además, XChaCha20 no requiere instrucciones especiales de hardware (como AES-NI) para ser rápido, lo que lo hace eficiente en cualquier plataforma.

Paso 4: Datos Adicionales Autenticados (AAD)

Los puntos efímeros E y V que forman parte de la cápsula se incluyen como Additional Authenticated Data (AAD) en el proceso de cifrado. Los AAD son datos que no se cifran —permanecen en claro y son visibles para cualquiera—, pero que quedan vinculados criptográficamente al texto cifrado mediante el MAC. Esto significa que si alguien intenta sustituir la cápsula (E, V) por otra diferente, manteniendo el mismo texto cifrado, la verificación del MAC fallará y el descifrado será rechazado. Es un vínculo indestructible entre la cápsula y el mensaje cifrado: no puedes mezclar componentes de diferentes cifrados.

Paso 5: La prueba de Schnorr, el sello de autenticidad

El último componente de la cápsula es una prueba de conocimiento de Schnorr. Esta prueba demuestra matemáticamente que quien creó la cápsula conoce los valores secretos r y u que corresponden a los puntos E y V. ¿Por qué es necesario? Porque sin esta prueba, un atacante podría fabricar una cápsula con puntos arbitrarios y conseguir que el proxy la re-cifre, potencialmente obteniendo información sobre las claves de re-cifrado.

La prueba de Schnorr funciona según el paradigma de compromiso-desafío-respuesta. El creador de la cápsula elige un valor aleatorio, calcula un «compromiso» público a partir de ese valor, luego combina el compromiso con los datos de la cápsula para generar un «desafío» (usando una función hash), y finalmente calcula una «respuesta» que solo es posible si se conocen los secretos originales. Cualquiera puede verificar la prueba —comprobar que el compromiso, el desafío y la respuesta son consistentes— sin aprender nada sobre los valores secretos. Esta propiedad se llama zero-knowledge (conocimiento cero): la prueba convence de que algo es verdad sin revelar por qué es verdad.

La versión utilizada es no interactiva, basada en la heurística de Fiat-Shamir: en lugar de que un verificador envíe un desafío aleatorio (lo que requeriría comunicación ida y vuelta), el desafío se genera como el hash de los datos públicos. Esto permite que la prueba se genere y se verifique de forma independiente, sin interacción.

La cápsula final contiene tres elementos: (E, V, prueba_schnorr). Junto con el texto cifrado y el nonce de XChaCha20, forma un paquete completo y autocontenido que puede almacenarse en un disco, transmitirse por la red o guardarse en una base de datos, listo para ser re-cifrado cuando sea necesario.

La clave de re-cifrado (KFrag): la instrucción que transforma sin revelar

Imagina que eres el director de un banco y necesitas que ciertos empleados puedan redirigir correspondencia entre clientes. Le das a un empleado una tarjeta con instrucciones codificadas que dice, en esencia: «cuando llegue un sobre dirigido al cliente A, estampa este sello especial y redirigelo al cliente B». El empleado puede seguir las instrucciones al pie de la letra —transformar sobres— pero la tarjeta no le permite abrir ningún sobre, ni el del cliente A ni el del cliente B. Tampoco puede usar la tarjeta para redirigir sobres en la dirección contraria (de B hacia A), ni puede combinar dos tarjetas diferentes para crear una redirección que no estaba autorizada.

Cuando Alice decide que Bob debe poder acceder a ciertos datos cifrados, genera lo que se conoce como una clave de re-cifrado o KFrag (Key Fragment). Para crearla, Alice necesita dos ingredientes: su propia clave privada (sk_Alice) y la clave pública de Bob (pk_Bob). A partir de estos, calcula un escalar especial —un número— que, cuando se aplica como multiplicador a los puntos de una cápsula cifrada para Alice, produce puntos que Bob puede usar con su propia clave privada para llegar al mismo secreto compartido original.

La construcción matemática del KFrag incorpora un nonce aleatorio específico para cada generación. Este nonce cumple dos funciones de seguridad fundamentales. En primer lugar, garantiza la unidireccionalidad: un KFrag que permite transformar de Alice a Bob no puede invertirse para transformar de Bob a Alice. La transformación es un camino de una sola dirección. En segundo lugar, proporciona no transitividad controlada: aunque el proxy posea un KFrag de Alice a Bob y otro de Bob a Carol, no puede combinarlos para fabricar un KFrag directo de Alice a Carol. Cada delegación es independiente y requiere la participación activa del delegador original.

Además del escalar de re-cifrado, cada KFrag incluye un compromiso criptográfico (commitment). Este compromiso es un punto de la curva elíptica que permite a cualquier verificador comprobar que el re-cifrado se ha realizado con el KFrag correcto, sin revelar cuál es el valor del KFrag. Es otra aplicación del principio de conocimiento cero: se puede verificar la corrección de una operación sin aprender nada sobre los datos secretos involucrados.

Un aspecto práctico crucial: generar un KFrag es una operación que Alice realiza una sola vez. A partir de ese momento, el proxy puede re-cifrar cualquier número de cápsulas —cientos, miles, millones— sin que Alice intervenga ni esté siquiera conectada. Alice puede generar el KFrag, entregárselo al proxy y desconectarse. El proxy seguirá transformando cápsulas de forma autónoma hasta que Alice revoque el KFrag.

El re-cifrado: la transformación ciega

Imagina una cadena de montaje en una fábrica. En un extremo, entran paquetes sellados con etiquetas de destino. Un robot en el centro de la cadena lee un código de barras en la etiqueta, consulta una tabla de instrucciones (el KFrag) y, siguiendo esas instrucciones de forma puramente mecánica, reimprime la etiqueta con un nuevo destino. El robot nunca abre el paquete. No tiene mecanismo para abrirlo; sus brazos mecánicos solo pueden manipular la etiqueta exterior. Tampoco entiende las instrucciones que sigue: son una secuencia de operaciones numéricas que produce un resultado correcto sin que el robot comprenda su significado. El paquete sale de la cadena con una nueva etiqueta, intacto e inviolado.

El re-cifrado es, en términos matemáticos, una multiplicación de puntos de la curva elíptica. Dado un KFrag con escalar rk y una cápsula con puntos (E, V), el proxy calcula:

• E' = rk · E
• V' = rk · V

El resultado, (E', V'), se denomina CFrag (Ciphertext Fragment). Cuando Bob reciba este CFrag, aplicará su clave privada sk_Bob y, gracias a las propiedades algebraicas de las curvas elípticas, llegará al mismo punto secreto compartido que Alice habría obtenido al descifrar la cápsula original. Ese punto secreto, pasado por la misma función KDF, producirá la misma clave simétrica, y con esa clave Bob descifrará el mensaje.

¿Por qué el proxy no puede derivar la clave simétrica por sí mismo? Porque para hacerlo necesitaría conocer o bien la clave privada de Alice, o bien la clave privada de Bob, o bien los escalares efímeros r y u originales. No tiene ninguno de estos valores. Lo que tiene es el KFrag y los puntos públicos de la cápsula. Para extraer el secreto a partir de estos elementos, necesitaría resolver el Problema del Logaritmo Discreto en Curvas Elípticas, que —como explicamos antes— requiere más operaciones de las que la humanidad puede realizar.

La prueba de Chaum-Pedersen: demostrar corrección sin revelar secretos

Hay un problema práctico: ¿cómo sabe Bob que el proxy ha re-cifrado correctamente? Un proxy malicioso o defectuoso podría aplicar un escalar incorrecto, produciendo un CFrag inválido. Bob intentaría descifrar y obtendría basura, sin poder distinguir entre un proxy que ha cometido un error y un proxy que está intentando sabotear la comunicación.

Para resolver esto, cada CFrag incluye una prueba de corrección de Chaum-Pedersen. Esta prueba, desarrollada por los criptógrafos David Chaum y Torben Pedersen, demuestra que el proxy ha utilizado el mismo escalar (el KFrag) para transformar tanto E como V. Es decir, demuestra que E'/E = V'/V en términos de logaritmo discreto, sin revelar cuál es ese logaritmo.

El procedimiento técnico es el siguiente. El proxy genera un escalar aleatorio k y calcula dos compromisos: U₁ = k · E y U₂ = k · V. Luego calcula un desafío como el hash de todos los puntos involucrados: c = H(E, E', V, V', U₁, U₂). Finalmente, calcula la respuesta s = k - c · rk. Bob verifica la prueba comprobando que s · E + c · E' = U₁ y que s · V + c · V' = U₂. Si ambas ecuaciones se cumplen, el re-cifrado es correcto. Si alguna falla, Bob sabe con certeza que el proxy ha actuado incorrectamente y puede rechazar el CFrag.

Esta prueba es, de nuevo, zero-knowledge: Bob queda absolutamente convencido de que la transformación es correcta, pero no aprende nada sobre el valor del KFrag. Ni siquiera sabe si el proxy ha usado un KFrag «grande» o «pequeño»; solo sabe que es consistente.

Threshold PRE: distribuir la confianza para eliminar puntos únicos de fallo

Hasta ahora hemos asumido que un solo proxy realiza todo el re-cifrado. Pero ¿qué pasa si ese proxy se cae? ¿Y si es comprometido por un atacante? ¿Y si el operador del proxy decide actuar de mala fe? Un solo proxy es un punto único de fallo, y en sistemas de seguridad, los puntos únicos de fallo son inaceptables.

Threshold PRE resuelve este problema distribuyendo el poder de re-cifrado entre múltiples proxies. En lugar de generar un solo KFrag, Alice genera n fragmentos (KFrags), y configura el sistema para que solo se necesiten t de ellos (donde t ≤ n) para completar un re-cifrado. Este esquema se conoce como (t, n)-threshold: t es el umbral mínimo y n es el número total de fragmentos.

Piensa en la cámara acorazada de un banco. La puerta tiene cinco cerraduras, cada una con una llave diferente, y cada llave está en manos de un directivo distinto. Pero la puerta no necesita las cinco llaves para abrirse: basta con que tres cualesquiera de los cinco directivos inserten sus llaves simultáneamente. Esto significa que dos directivos conspirando juntos no pueden abrir la cámara, pero tampoco es necesario que los cinco estén presentes. Si uno está de viaje y otro está enfermo, los tres restantes pueden operar con normalidad. El sistema es resiliente a ausencias y resistente a conspiraciones de hasta dos miembros.

Shamir's Secret Sharing: la matemática del secreto compartido

La base matemática del threshold PRE es un algoritmo inventado en 1979 por Adi Shamir (la «S» de RSA), llamado Shamir's Secret Sharing. El principio es sorprendentemente elegante y se basa en una propiedad fundamental de los polinomios: un polinomio de grado t-1 queda completamente determinado por exactamente t puntos. Con t-1 puntos o menos, hay infinitos polinomios posibles, y el secreto puede ser cualquier valor.

Veámoslo con un ejemplo numérico concreto. Supongamos que el secreto es el número 42, y queremos un esquema (3, 5): cinco participantes, y cualquier grupo de tres puede reconstruir el secreto. Necesitamos un polinomio de grado 2 (porque t-1 = 2) cuyo valor en x = 0 sea 42. Elegimos dos coeficientes aleatorios, por ejemplo 7 y 3:

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

Ahora evaluamos el polinomio en cinco puntos:

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

Cada participante recibe su par (i, f(i)). El participante 1 sabe que su «share» es (1, 52), pero no conoce el polinomio completo ni el secreto.

Reconstrucción por interpolación de Lagrange

Supongamos que los participantes 1, 3 y 5 quieren reconstruir el secreto. Usan la interpolación de Lagrange, un método matemático que encuentra el único polinomio que pasa por un conjunto dado de puntos. Para evaluar el polinomio en x = 0 (donde está el secreto), calculan los coeficientes de Lagrange:

Para el participante 1 (x₁ = 1): L₁(0) = (0-3)(0-5) / (1-3)(1-5) = (-3)(-5) / (-2)(-4) = 15/8

Para el participante 3 (x₃ = 3): L₃(0) = (0-1)(0-5) / (3-1)(3-5) = (-1)(-5) / (2)(-2) = 5/(-4) = -5/4

Para el participante 5 (x₅ = 5): L₅(0) = (0-1)(0-3) / (5-1)(5-3) = (-1)(-3) / (4)(2) = 3/8

El secreto es: f(0) = 52 · (15/8) + 90 · (-5/4) + 152 · (3/8) = 780/8 - 450/4 + 456/8 = 97.5 - 112.5 + 57 = 42

El secreto 42 ha sido reconstruido perfectamente. Lo fascinante es que si los participantes 1 y 3 intentaran reconstruirlo solos (con solo dos puntos), podrían encontrar infinitos polinomios de grado 2 que pasan por esos dos puntos, cada uno dando un valor diferente en x = 0. Con dos shares, el secreto podría ser cualquier número con la misma probabilidad. Esto se llama seguridad información-teórica: incluso con potencia computacional infinita, un atacante que posea menos de t shares no obtiene absolutamente ninguna información sobre el secreto.

Feldman VSS: verificar sin revelar

El esquema de Shamir tiene una debilidad: requiere confianza en que Alice ha distribuido shares correctos. Un distribuidor malicioso podría dar a uno de los participantes un share incorrecto, lo que haría que la reconstrucción falle o, peor, produzca un secreto equivocado. Feldman's Verifiable Secret Sharing (VSS) resuelve esto añadiendo una capa de verificación pública.

Alice, además de distribuir los shares, publica compromisos de los coeficientes del polinomio. Para cada coeficiente aⱼ, publica el punto Cⱼ = aⱼ · G. Nadie puede deducir aⱼ a partir de Cⱼ (gracias al problema del logaritmo discreto), pero cada participante puede verificar que su share es consistente con los compromisos publicados. El participante i comprueba que:

f(i) · G = C₀ + i · C₁ + i² · C₂ + ... + i^(t-1) · C_(t-1)

El lado izquierdo lo calcula con su share privado. El lado derecho lo calcula con los compromisos públicos. Si ambos coinciden, el share es correcto. Si no coinciden, el participante sabe con certeza que Alice le ha dado un share falso y puede denunciarlo públicamente. Esto convierte la distribución de secretos en un proceso verificable: nadie necesita confiar ciegamente en nadie.

Cómo funciona todo junto en Threshold PRE

En la práctica, Alice genera n KFrags usando el esquema de Shamir aplicado al escalar de re-cifrado. Cada proxy recibe un KFrag diferente. Cuando hay que re-cifrar una cápsula, al menos t proxies aplican sus respectivos KFrags, produciendo t CFrags diferentes. Bob recibe estos CFrags y los recombina usando los coeficientes de Lagrange, obteniendo el equivalente del re-cifrado completo.

Esto proporciona tres propiedades simultáneas: disponibilidad (el sistema funciona mientras al menos t proxies estén operativos, tolerando hasta n - t caídas), seguridad distribuida (un atacante necesita comprometer al menos t proxies para obtener el KFrag completo) y verificabilidad (cada CFrag incluye su propia prueba de Chaum-Pedersen, permitiendo detectar y descartar CFrags de proxies defectuosos o maliciosos).

Multi-hop: cadenas de delegación controlada

En algunos escenarios, la delegación necesita ser transitiva de forma controlada. Alice delega a Bob, y Bob a su vez delega a Carol. Esto es lo que se conoce como multi-hop PRE: cada «salto» es un re-cifrado independiente, con sus propios KFrags y sus propias garantías.

La cadena Alice → Bob → Carol implica dos re-cifrados sucesivos. Primero, un proxy re-cifra la cápsula de Alice para Bob, produciendo un CFrag. Después, Bob genera nuevos KFrags (a partir de su propia clave privada y la clave pública de Carol), y otro proxy (o el mismo) re-cifra el CFrag resultante para Carol. Carol termina con un texto cifrado que puede descifrar con su clave privada, aunque los datos originales fueron cifrados exclusivamente para Alice.

El diseño multi-hop incorpora un mecanismo llamado chain binding (vinculación de cadena): cada CFrag contiene información criptográfica que lo vincula a la cadena específica por la que ha viajado. Un CFrag generado en la cadena Alice → Bob → Carol no puede intercambiarse con un CFrag de una cadena diferente, por ejemplo Alice → David → Carol. Esto impide ataques de «mix-and-match» donde un adversario intenta recombinar CFrags de diferentes cadenas para obtener acceso no autorizado.

Cada salto de la cadena puede tener un threshold diferente. Alice puede requerir un esquema (3, 5) para su delegación a Bob, mientras que Bob puede usar un esquema (2, 3) para su delegación a Carol. Esto permite políticas de acceso granulares que se adaptan al nivel de confianza y al riesgo en cada etapa de la cadena.

Seguridad en profundidad: las capas invisibles de protección

La criptografía matemática es la primera línea de defensa, pero no es la única. En la práctica, los ataques más efectivos no intentan romper la matemática: explotan debilidades en cómo se implementa la matemática. Un algoritmo teóricamente perfecto puede ser completamente inseguro si el código que lo ejecuta filtra información por canales indirectos. Esta sección explora las medidas de seguridad que protegen contra estos ataques de implementación.

Operaciones en tiempo constante: derrotando a los espías del reloj

En 1996, el criptógrafo Paul Kocher demostró que podía extraer claves criptográficas midiendo el tiempo que un procesador tardaba en realizar operaciones. No necesitaba acceder a la memoria, ni instalar malware, ni siquiera estar cerca del ordenador: bastaba con medir, con precisión de nanosegundos, cuánto tiempo tardaba el servidor en responder a diferentes peticiones.

El ataque explota un hecho fundamental de la computación: las instrucciones condicionales (if/else) tardan tiempos diferentes dependiendo de qué rama se ejecuta. Si un algoritmo criptográfico contiene código como «si el bit 47 de la clave es 1, haz esto; si es 0, haz aquello», un atacante que pueda medir el tiempo de ejecución puede deducir, bit por bit, cuál es la clave. Esto se conoce como ataque de canal lateral por temporización (timing side-channel attack).

La defensa son las operaciones en tiempo constante. En lugar de ejecutar una rama u otra, el código calcula ambos resultados (el correspondiente al bit 0 y el correspondiente al bit 1) y luego selecciona el correcto mediante una operación aritmética que tarda exactamente lo mismo para ambos valores. Por ejemplo, la selección se realiza con una multiplicación por máscara de bits: resultado = (bit · valor_si_1) | ((1-bit) · valor_si_0). Ambos productos se calculan siempre, ambas operaciones OR se ejecutan siempre, y el resultado es correcto en ambos casos. Un observador externo no puede distinguir qué valor de bit se usó.

Las bibliotecas como curve25519-dalek, que implementan la aritmética de curva elíptica utilizada en PRE, aplican este principio a cada operación: sumas de puntos, multiplicaciones escalares, comparaciones. El coste en rendimiento es significativo —típicamente un factor de 2x a 3x respecto al código «ingenuo»—, pero es un precio que se paga una vez para inmunizar el sistema contra toda una clase de ataques.

Zeroize: el arte de borrar de verdad

Cuando un programa termina de usar una variable —por ejemplo, una clave privada que ya no necesita—, la marca como «libre» y el sistema operativo puede reutilizar esa zona de memoria para otras cosas. Pero «libre» no significa «borrada»: los datos siguen ahí, en la RAM, como letras escritas a lápiz y no borradas. Pueden persistir durante milisegundos, segundos o incluso minutos, esperando a ser sobrescritos por casualidad. Durante ese tiempo, un volcado de memoria (por un error, por un ataque, por una herramienta forense) podría recuperar la clave.

La solución obvia es sobrescribir la variable con ceros antes de liberarla. Pero los compiladores modernos son demasiado inteligentes para nuestro propio bien. Un compilador optimizador detecta que estás escribiendo ceros en una variable que no vas a volver a usar, y elimina esa escritura por considerarla «innecesaria». El compilador tiene razón desde el punto de vista de la lógica del programa —el programa se comporta igual con o sin esa escritura—, pero está equivocado desde el punto de vista de la seguridad.

El mecanismo Zeroize resuelve esto utilizando escrituras volátiles (volatile writes): instrucciones que le dicen al compilador «esta escritura tiene efectos secundarios que no puedes ver; no la elimines». Es una barrera que impide al optimizador eliminar la limpieza de memoria. El trait ZeroizeOnDrop va un paso más allá: garantiza que la limpieza ocurre automáticamente cuando la variable sale del ámbito de ejecución, incluso si el programa termina por un error inesperado. Es un seguro automático contra la negligencia del programador y los caprichos del compilador.

Blinding: ocultar hasta los metadatos

Incluso si el proxy no puede descifrar los datos, podría aprender quién comparte datos con quién. Si Alice envía al proxy cápsulas etiquetadas con su identidad y KFrags que contienen la clave pública de Bob, el proxy sabe que Alice está compartiendo algo con Bob. En muchos contextos —médicos, legales, empresariales—, el simple hecho de que dos partes estén intercambiando información es, en sí mismo, información sensible.

El blinding (cegado u ofuscación) resuelve esto. Antes de enviar la cápsula al proxy, se multiplica por un factor aleatorio —el «factor de cegado»— que enmascara la cápsula original. El proxy recibe y procesa la cápsula cegada, produciendo un CFrag cegado. El resultado se envía de vuelta, y el factor de cegado se «deshace» matemáticamente para obtener el CFrag correcto. El proxy ha realizado el re-cifrado correctamente, pero lo ha hecho sobre una cápsula que no puede vincular con ninguna identidad ni con ninguna otra cápsula anterior. Ha operado a ciegas, en el sentido más literal y más criptográfico del término.

AEAD y Schnorr: la doble barrera contra la manipulación

La combinación de cifrado autenticado (AEAD) y pruebas de Schnorr crea una doble barrera contra los ataques de manipulación. El AEAD protege el mensaje cifrado: cualquier modificación del texto cifrado o de los datos asociados (la cápsula) invalida el MAC y el descifrado falla. La prueba de Schnorr protege la cápsula: demuestra que fue creada por alguien que conoce los secretos correspondientes, impidiendo que un atacante inyecte cápsulas fabricadas.

Juntas, estas dos medidas impiden los ataques de texto cifrado elegido (chosen-ciphertext attacks, CCA). En un ataque CCA, el adversario puede enviar textos cifrados arbitrarios al oráculo de descifrado y observar los resultados (o los errores) para deducir información sobre la clave. Las pruebas de Schnorr impiden enviar cápsulas fabricadas (porque no pasarán la verificación), y el AEAD impide modificar cápsulas legítimas (porque cualquier cambio invalida el MAC). El resultado es un sistema con seguridad IND-CCA2, el nivel más alto de seguridad definido formalmente para esquemas de cifrado.

Rotación y revocación: gestionar el ciclo de vida del acceso

Proactive refresh: cambiar las cerraduras sin cambiar la puerta

Imagina un edificio donde las cerraduras de todas las puertas se cambian automáticamente cada lunes a las tres de la madrugada. Los empleados autorizados encuentran sus nuevas llaves en sus buzones cada lunes por la mañana. Si un ladrón robó una llave el viernes anterior, el lunes ya no le sirve. Si un espía copió una llave hace tres semanas, esa copia es inútil. Las cerraduras cambian, pero las puertas y las habitaciones siguen siendo las mismas: nadie necesita mover ni re-cifrar nada.

El proactive refresh (refresco proactivo) es un mecanismo que permite renovar todos los KFrags sin cambiar las claves subyacentes ni re-cifrar los datos almacenados. Funciona mediante un truco algebraico elegante: se genera un nuevo polinomio aleatorio g(x) de grado t-1 con la condición de que g(0) = 0. Los nuevos shares se calculan sumando las evaluaciones de este polinomio a los shares existentes:

f'(i) = f(i) + g(i)

Como g(0) = 0, el secreto no cambia: f'(0) = f(0) + g(0) = f(0) + 0 = f(0). El secreto original permanece intacto. Pero todos los shares individuales son completamente nuevos e incompatibles con los anteriores. Un atacante que haya conseguido uno o varios shares de la época anterior no puede combinarlos con shares de la época actual: son matemáticamente incompatibles, como llaves de cerraduras diferentes.

Esto proporciona una propiedad conocida como seguridad hacia delante (forward security): incluso si un atacante logra comprometer shares a lo largo del tiempo, la ventana de vulnerabilidad se limita a cada época individual. Necesitaría comprometer t shares dentro de la misma época para reconstruir el secreto, y cada refresh le obliga a empezar de cero.

Revocación instantánea y expiración automática

Los KFrags pueden incorporar una marca de expiración (valid_until): una fecha y hora a partir de la cual los proxies deben rechazar automáticamente cualquier solicitud de re-cifrado con ese KFrag. Esto permite delegaciones temporales sin intervención manual: «comparte mis documentos con el auditor hasta el 31 de marzo» se traduce en un KFrag con expiración incorporada.

La revocación inmediata es aún más sencilla: basta con instruir a los proxies para que eliminen el KFrag. Una vez eliminado, no es posible re-cifrar nuevas cápsulas. Los datos ya cifrados no se tocan —siguen en su almacenamiento original, intactos—, simplemente el proxy pierde la capacidad de transformarlos para el destinatario revocado. La revocación es instantánea, no tiene coste computacional sobre los datos y no requiere re-cifrar nada. Contrasta esto con los sistemas de cifrado tradicionales, donde revocar acceso a menudo implica descargar todos los datos, descifrarlos y re-cifrarlos con nuevas claves: un proceso lento, costoso y que crea una ventana de vulnerabilidad.

Casos de uso: dónde se aplica esta tecnología en la práctica

Salud: el historial médico bajo el control del paciente

María tiene 45 años y un historial médico extenso: análisis de sangre, radiografías, informes de cardiología, resultados de pruebas genéticas y registros de varias intervenciones quirúrgicas. Todo está almacenado en el sistema del Hospital Central, cifrado con su clave pública personal. Solo María puede acceder a sus datos.

Un día, María nota molestias en el pecho y su médico de cabecera la deriva al Dr. García, un cardiólogo del Hospital Universitario. El Dr. García necesita ver los informes de cardiología de María, pero no sus pruebas genéticas, ni sus análisis de sangre rutinarios, ni los registros de una intervención de rodilla de hace diez años. En un sistema tradicional, María tendría que firmar una autorización genérica que daría al Dr. García acceso a todo su historial, o bien alguien del Hospital Central tendría que descargar manualmente los documentos relevantes, descifrarlos y reenviarlos al Hospital Universitario. Ambas opciones son problemáticas: la primera viola el principio de minimización de datos (el Dr. García accede a más información de la que necesita), y la segunda requiere intervención humana, es lenta y crea copias en claro de los datos durante el proceso.

Con Proxy Re-Encryption, María genera un KFrag específico que permite al proxy del Hospital Central re-cifrar exclusivamente los documentos etiquetados como «cardiología» para la clave pública del Dr. García. El proxy transforma los documentos de cardiología —y solo esos— de modo que el Dr. García pueda descifrarlos con su clave privada. El proxy nunca ve el contenido de los documentos. El Dr. García nunca accede a las pruebas genéticas ni a los análisis de sangre. Y todo el proceso es automático: María genera el KFrag una vez, y a partir de ese momento cada nuevo informe de cardiología que se añada a su historial será accesible para el Dr. García sin que María tenga que intervenir.

Cuando María termine su tratamiento con el Dr. García, revoca el KFrag. El acceso se corta instantáneamente. No hay que eliminar copias (porque nunca se crearon copias), no hay que re-cifrar documentos (porque los originales nunca se tocaron), y queda un registro verificable —las pruebas de Chaum-Pedersen— de exactamente qué documentos fueron re-cifrados y cuándo. Esto cumple de forma nativa los principios del RGPD: minimización de datos, limitación de finalidad, limitación temporal y derecho de revocación.

Almacenamiento en la nube: zero-knowledge de verdad

Carlos dirige una startup de tecnología y almacena toda la propiedad intelectual de su empresa —código fuente, patentes en preparación, estrategia comercial— en un servicio de almacenamiento en la nube. El proveedor promete «cifrado end-to-end», pero Carlos ha leído la letra pequeña: el proveedor gestiona las claves. Esto significa que técnicamente puede descifrar los datos si quiere, si recibe un requerimiento judicial, si es comprado por un competidor, o si un empleado con acceso privilegiado decide curiosear.

Carlos migra a un sistema basado en PRE. Ahora, sus archivos se cifran con su clave pública antes de subirse a la nube. El proveedor almacena datos que no puede descifrar. Cuando Carlos necesita que su CTO acceda a los documentos técnicos, genera un KFrag que autoriza al proveedor (que actúa como proxy) a re-cifrar esos documentos específicos para la clave pública del CTO. El proveedor realiza la transformación —es una operación computacionalmente barata—, pero en ningún momento ve el contenido de los archivos.

Un día, el proveedor de nube sufre una brecha de seguridad. Los atacantes acceden a todos los servidores y descargan terabytes de datos. Pero lo que descargan son bloques de bytes cifrados con claves que el proveedor nunca tuvo. Los KFrags que el proveedor almacenaba permiten transformar cifrados, no descifrarlos. Sin la clave privada de Carlos o de su CTO, los datos son indistinguibles de ruido aleatorio. La brecha de seguridad no expone ni un solo byte de información útil. Esto es lo que significa zero-knowledge real: no «el proveedor promete no mirar», sino «el proveedor no puede mirar aunque quiera».

RGPD: delegación de datos que cumple la ley por diseño

Una empresa de recursos humanos gestiona datos sensibles de miles de empleados de sus clientes: nóminas, evaluaciones de rendimiento, datos de salud laboral, registros disciplinarios. El RGPD exige que estos datos se traten con bases jurídicas claras, finalidades específicas, plazos definidos y la posibilidad de revocar el consentimiento en cualquier momento. Implementar todo esto con cifrado tradicional es una pesadilla operativa.

Con PRE, cada delegación de datos queda codificada en un KFrag que es, en sí mismo, una representación criptográfica de la política de acceso. El KFrag vincula una identidad concreta (el delegador), un destinatario concreto (el delegatario), un alcance concreto (qué datos), y puede incorporar una expiración temporal. Si la empresa necesita que un auditor externo revise las nóminas del tercer trimestre, genera un KFrag que permite re-cifrar exclusivamente los documentos de nóminas de julio a septiembre para la clave del auditor, con expiración el 31 de diciembre. El auditor accede a lo que necesita, durante el tiempo que necesita, y el acceso se extingue automáticamente.

Cuando un empleado ejerce su derecho de revocación, el proceso es inmediato: se eliminan los KFrags asociados a sus datos. Ningún proxy puede seguir re-cifrando. Las pruebas de Chaum-Pedersen proporcionan un rastro de auditoría criptográficamente verificable: no es un log que alguien pueda falsificar, sino una prueba matemática de qué transformaciones se realizaron y cuándo. La conformidad regulatoria no es un proceso manual de revisión y documentación: está integrada en la arquitectura criptográfica del sistema.

Blockchain y datos privados: cómo conseguir reglas de acceso públicas y verificables

La tecnología blockchain —un registro digital distribuido, inmutable y público— tiene una tensión inherente con la privacidad. Todo lo que se escribe en una blockchain es visible para todos los participantes de la red, para siempre. Esto es una virtud cuando hablamos de transparencia financiera o de trazabilidad de cadenas de suministro, pero es un problema grave cuando los datos que necesitamos almacenar son confidenciales.

Un contrato inteligente —un programa que se ejecuta automáticamente en la blockchain cuando se cumplen ciertas condiciones— podría, por ejemplo, gestionar el acceso a historiales de propiedad intelectual de una empresa. Los documentos están cifrados con la clave de la empresa y almacenados en la blockchain (o, más comúnmente, su hash está en la blockchain y los datos cifrados en un almacenamiento descentralizado como IPFS). El contrato inteligente codifica las reglas de acceso: «permitir re-cifrado para cualquier dirección que posea al menos 1000 tokens de gobernanza y haya completado un proceso de verificación de identidad (KYC)».

Cuando un inversor que cumple estas condiciones solicita acceso, el contrato inteligente autoriza automáticamente la generación del KFrag correspondiente. Los proxies de la red re-cifran los documentos para la clave del inversor. Todo el proceso queda registrado en la blockchain: quién solicitó acceso, cuándo fue autorizado, qué documentos fueron re-cifrados. Pero el contenido de los documentos permanece cifrado en todo momento; solo el inversor autorizado puede descifrarlos. Se consigue una combinación aparentemente imposible: la inmutabilidad y transparencia de la blockchain para las reglas y los registros de acceso, y la privacidad absoluta del cifrado para los datos en sí. Las reglas son públicas; los datos, privados.

El horizonte post-cuántico: prepararse para una amenaza que aún no existe

¿Qué es un ordenador cuántico y por qué debería importarnos?

Un ordenador clásico —el que usas ahora mismo— procesa información en bits: unidades que pueden ser 0 o 1, como interruptores que están encendidos o apagados. Un ordenador cuántico procesa información en qubits (quantum bits), que pueden estar en una superposición de 0 y 1 simultáneamente. Esto no significa que un qubit sea «0 y 1 a la vez» en un sentido clásico, sino que la mecánica cuántica permite que el qubit se encuentre en un estado probabilístico que colapsa a 0 o a 1 solo cuando se mide.

¿Por qué esto es relevante para la criptografía? Porque la superposición y otro fenómeno cuántico llamado entrelazamiento permiten que un ordenador cuántico explore exponencialmente más posibilidades en paralelo que un ordenador clásico. Para ciertos problemas —no para todos, sino para una clase específica de problemas matemáticos—, un ordenador cuántico puede encontrar la solución en un tiempo radicalmente menor.

El algoritmo de Shor: la llave maestra teórica

En 1994, el matemático Peter Shor publicó un algoritmo que demostró algo perturbador: un ordenador cuántico suficientemente grande podría factorizar números enteros y calcular logaritmos discretos en tiempo polinómico. Traducido: podría romper RSA y la criptografía de curva elíptica.

El algoritmo de Shor funciona, simplificando enormemente, así: convierte el problema del logaritmo discreto en un problema de encontrar el período de una función. Encontrar períodos es algo que los ordenadores cuánticos hacen extraordinariamente bien, gracias a una técnica llamada Transformada de Fourier Cuántica. Un ordenador clásico necesitaría del orden de 2¹²⁸ operaciones para encontrar el período en una curva elíptica de 256 bits. Un ordenador cuántico con suficientes qubits podría hacerlo en unas pocas miles de operaciones cuánticas.

Hoy en día, los ordenadores cuánticos más avanzados tienen unos pocos miles de qubits, y la mayoría son «ruidosos» (propensos a errores). Los expertos estiman que romper Curve25519 requeriría del orden de varios miles de qubits lógicos (libres de errores), lo que con la tecnología actual se traduce en millones de qubits físicos. No estamos ahí todavía, y las estimaciones sobre cuándo llegaremos varían entre «diez años» y «nunca». Pero hay un problema insidioso: los datos cifrados hoy con curvas elípticas podrían estar siendo recopilados ahora por adversarios que esperan tener un ordenador cuántico en el futuro para descifrarlos. Este ataque se conoce como «harvest now, decrypt later» (recopilar ahora, descifrar después), y es una amenaza real para datos que necesitan mantener su confidencialidad durante décadas: secretos de estado, propiedad intelectual, historiales médicos.

La respuesta: cifrado híbrido y crypto-agility

La comunidad criptográfica no ha esperado a que los ordenadores cuánticos sean una realidad para preparar la respuesta. El Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) ha publicado recientemente nuevos estándares de criptografía post-cuántica, diseñados para resistir tanto ataques clásicos como cuánticos. El más relevante para PRE es ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, publicado como FIPS 203), un mecanismo de encapsulación de claves basado en retículos (lattices): estructuras matemáticas cuya dificultad no se ve afectada por el algoritmo de Shor.

La estrategia recomendada es el cifrado híbrido: combinar el esquema de curvas elípticas actual con ML-KEM. La cápsula contendría dos encapsulaciones paralelas, una elíptica y una basada en retículos. La clave simétrica final se derivaría combinando ambos secretos compartidos. La seguridad del sistema híbrido es la del más fuerte de los dos esquemas: si las curvas elípticas son rotas por un ordenador cuántico, ML-KEM sigue protegiendo; si ML-KEM resulta tener una vulnerabilidad clásica desconocida, las curvas elípticas siguen protegiendo.

Para que esta migración sea práctica, el sistema necesita crypto-agility: la capacidad de cambiar las primitivas criptográficas subyacentes sin rediseñar todo el sistema. Esto se logra abstrayendo las primitivas como interfaces (traits en Rust), versionando las cápsulas (una cápsula v1 usa solo curvas elípticas; una cápsula v2 usa el esquema híbrido) y manteniendo la compatibilidad hacia atrás. Los datos cifrados con cápsulas v1 siguen siendo descifrables; los datos nuevos se cifran con cápsulas v2. La migración es gradual, sin re-cifrado masivo y sin interrupciones del servicio.

Para saber más

• AFGH 2006 — Ateniese, Fu, Green, Hohenberger. Improved Proxy Re-Encryption Schemes with Applications to Secure Distributed Storage. El paper fundacional que define los esquemas PRE unidireccionales y CCA-seguros. Introduce la construcción basada en emparejamientos bilineales que inspira las implementaciones modernas.
• RFC 7748 — Elliptic Curves for Security (Curve25519/X25519). La especificación formal de Curve25519 y la función de intercambio de claves X25519. Define la aritmética de la curva, las representaciones de puntos y las consideraciones de seguridad de implementación.
• RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols. Define el algoritmo de cifrado de flujo ChaCha20 y el autenticador Poly1305. Explica las razones de diseño y las ventajas sobre AES-GCM en contextos donde no hay aceleración por hardware.
• FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). El estándar post-cuántico del NIST para encapsulación de claves. Describe el esquema basado en retículos que se propone como complemento o sustituto de ECDH para resistir ataques cuánticos.
• FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature). El estándar de firma digital post-cuántica del NIST. Relevante para futuras versiones de las pruebas de Schnorr y Chaum-Pedersen en un contexto post-cuántico.
• Shamir 1979 — How to Share a Secret. El paper original que introduce el esquema de secret sharing basado en polinomios. Breve, elegante y sorprendentemente accesible. La base teórica de todo esquema threshold.
• Feldman 1987 — A Practical Scheme for Non-interactive Verifiable Secret Sharing. Extiende el esquema de Shamir con compromisos criptográficos que permiten verificar la corrección de los shares sin revelar el secreto. Fundamental para threshold PRE en entornos con participantes potencialmente maliciosos.