- El cifrado homomórfico completo (FHE) es una tecnología que permite realizar operaciones sobre datos cifrados sin descifrarlos
- Actualmente, FHE todavía tiene limitaciones como una baja utilidad práctica, una reducción de velocidad de cálculo de 1,000x a 10,000x y un aumento de almacenamiento de 40x a 1,000x
- Sin embargo, recientemente los algoritmos de FHE han logrado una mejora de velocidad de 8x por año, y pronto podrían entrar en una zona práctica en áreas como computación en la nube, inferencia de LLM y contratos inteligentes de blockchain
- Si FHE se vuelve generalizado, impulsará un cambio industrial en el que la privacidad de los datos será el valor por defecto en todo el entorno de cómputo
- Cubre de forma integral conceptos clave como criptografía basada en retículas, LWE, bootstrapping, así como la historia de evolución de los algoritmos FHE, ejemplos reales de implementación y tendencias de mejora de rendimiento
Introducción: qué es el cifrado homomórfico completo
- El cifrado homomórfico completo (Fully Homomorphic Encryption, FHE) permite realizar operaciones arbitrarias sobre texto cifrado sin descifrarlo, lo que en la práctica hace posible operar directamente sobre datos cifrados
- Es decir, un servidor puede calcular y entregar preguntas y resultados sin conocer el texto plano
- Esta tecnología ya se está adoptando en varios sistemas del mundo real
El potencial y las limitaciones de FHE: la "ley de Moore de FHE"
- FHE puede mantener los datos cifrados de forma continua en la red, haciendo posible una privacidad total que bloquea de raíz el riesgo de fuga de datos
- Aun así, la razón por la que su adopción práctica sigue siendo limitada es la drástica degradación de rendimiento: las operaciones sobre texto cifrado son entre 1,000 y 10,000 veces más lentas que las operaciones sobre texto plano, y el almacenamiento también aumenta aproximadamente entre 40 y 1,000 veces
- Esto es similar a los primeros años de internet en la década de 1990
- Pero recientemente FHE se ha vuelto 8 veces más rápido cada año, por lo que se espera que pronto entre en varias áreas de uso práctico
Punto crítico: la adopción práctica de FHE se acerca
- Si este ritmo de avance explosivo se mantiene, en adelante FHE podría volverse práctico en áreas como las siguientes
- computación en la nube cifrada
- inferencia de LLM cifrada
- contratos inteligentes de blockchain con confidencialidad garantizada
- Este cambio podría sacudir desde la raíz el modelo de negocio de internet basado en la recolección de datos de usuarios
- Gracias a FHE, se espera una transición esencial desde una internet donde "la vigilancia es el valor por defecto" hacia una donde "la privacidad es el valor por defecto"
El talón de Aquiles de la seguridad de datos y la solución de FHE
- Los datos suelen descifrarse en el estado de "en uso" entre sus tres estados (almacenamiento, transmisión y uso), lo que se convierte en una vulnerabilidad de seguridad
- La nube, personal interno, hackers o CPU vulnerables pueden acceder a datos en texto plano dentro de la memoria
- La mayoría de las grandes filtraciones de datos también ocurren cuando los datos están "en uso" o "almacenados"
- FHE mantiene los datos cifrados durante todo su ciclo de vida y resuelve de raíz estas vulnerabilidades
Definición de computación con privacidad total
- El entorno ideal es uno donde los datos permanecen cifrados al almacenarse, transmitirse y usarse (procesarse)
- Por ejemplo, el servidor no ve en absoluto la pregunta en texto plano; recibe una pregunta cifrada y devuelve únicamente un resultado cifrado
- Solo el usuario puede descifrar ese resultado
Cómo funciona FHE: estructura y conceptos matemáticos
- "Homomórfico" se basa en una transformación matemática que preserva la misma estructura (por ejemplo, similar a la transformada de Fourier)
- FHE transforma bidireccionalmente entre el espacio de texto plano y el espacio de texto cifrado, de modo que descifrar el resultado de una operación sobre texto cifrado da el mismo resultado que operar sobre texto plano
- Para estas transformaciones se usan principalmente la criptografía basada en retículas y LWE (Learning With Errors)
- La criptografía basada en retículas plantea problemas vectoriales en dimensiones muy altas, y se considera difícil de resolver incluso para computadoras cuánticas (resistencia cuántica)
- LWE consiste en invertir un sistema lineal mezclado con ruido, algo que en la práctica es imposible de descifrar
Gestión del ruido y bootstrapping
- En FHE, a medida que se repiten las operaciones, aumenta el ruido dentro del texto cifrado
- En las sumas crece de forma lineal y en las multiplicaciones de forma geométrica, hasta llegar a un punto en que ya no se puede descifrar
- La tecnología clave para resolver esto es el bootstrapping, una técnica que vuelve a cifrar el texto cifrado con una "nueva clave pública" para reiniciar el ruido a un nivel manejable
- Este proceso es el cuello de botella de rendimiento en los sistemas FHE, pero está mejorando rápidamente año con año
Otros componentes clave de FHE
- relinearization: proceso que resuelve el problema de que, tras una multiplicación, el grado de la clave aumenta a segundo grado y lo devuelve a primer grado
- modulus switching: técnica que reduce el módulo del texto cifrado para gestionar el ruido
Además de esto, con la evolución de los algoritmos se siguen proponiendo distintas técnicas de forma continua
Clasificación de los esquemas de cifrado homomórfico (HE) y ejemplo en Python
- Cifrado homomórfico parcial (Partial HE): solo admite una operación (p. ej., el cifrado de Paillier solo admite suma)
- Cifrado homomórfico algo limitado (Somewhat HE): admite suma y multiplicación, pero con límite en la cantidad de multiplicaciones repetidas
- Cifrado homomórfico completo (FHE): admite suma y multiplicación sin límite. Garantiza completitud de Turing
Con un ejemplo del cifrado de Paillier implementado en Python se puede experimentar intuitivamente el homomorfismo parcial
Historia del desarrollo de FHE y la "ley de Moore de FHE"
- 1978: aparece por primera vez el concepto de "isomorfismo homomórfico de privacidad"
- 2009: primera realización de FHE por Craig Gentry (tesis doctoral)
- 2011: primera implementación, con 30 minutos por bit (extremadamente lenta)
- Desde 2013: el bootstrapping se reduce hasta el nivel de unos pocos ms
- 2017: CKKS y otros añaden soporte para aproximaciones de punto flotante, impulsando su adopción en ML/AI
Los algoritmos de FHE han mejorado 8x por año desde 2011, pasando de una sobrecarga inicial de 10¹⁰x a un nivel reciente de 10³~10⁴x
Los artículos más recientes han reducido el throughput de multiplicación de FHE en 1,000x y la latencia en 10x, y al combinarse con aceleración por hardware todavía habría margen para mejorar más de 1,000x adicionales
Un futuro donde el cifrado es el valor por defecto
- Las grandes filtraciones de datos son una realidad inevitable
- Si con FHE el servidor puede operar sobre datos cifrados sin tener la clave de descifrado, eso marcará un nuevo estándar de protección de la privacidad
- Aún no es totalmente práctico en todos los ámbitos, pero está mejorando a una velocidad sorprendente cada año
- Con la creciente exigencia de privacidad por parte de los usuarios y el endurecimiento de la regulación, se prevé que FHE termine convirtiéndose en el estándar para la mayor parte de la computación en la nube
- La computación en internet del futuro evolucionará para estar siempre cifrada
Década de 2010: HTTPS como valor por defecto
Próximamente: se espera la llegada de una era en la que FHE será el valor por defecto
Referencias y material adicional
- FHE Reference Library: recopilación integral de material académico
- Tesis doctoral de Craig Gentry de 2009: punto de partida de FHE
- Vitalik Buterin: análisis profundo de FHE
- Comunidad: FHE.org (hub centrado en desarrolladores)
- GitHub: awesome-he: colección de proyectos relacionados con cifrado homomórfico
1 comentarios
Comentarios de Hacker News
Voy a hablar dejando claro que me gustan muchísimo FHE y la cryptography. Aunque FHE se está volviendo cada vez más rápida, mientras dependa del bootstrapping no podrá alcanzar la velocidad de operación del texto plano. El overhead de más o menos 1000x causado por el bootstrapping es, en esencia, inevitable, y cuando se entendió que no era posible hacerlo mucho más rápido, empezó a hablarse de aceleración por hardware. Pero en esta época en la que toda la potencia de cómputo se la está llevando LLM, no es algo fácil. Si piensas cuánto se dispararía el costo por token al computar con FHE, salvo que no llegue ni a 1000x, en la práctica casi no tiene viabilidad. Si el objetivo es proteger la privacidad, por ahora la única alternativa práctica es confidential computing. No me encanta tener que confiar en el hardware, pero es lo mejor que tenemos
Hay una razón todavía más fundamental por la que cuesta usar FHE para cómputo arbitrario. Algunos tipos de operaciones se vuelven anormalmente más complejos sobre ciphertext que sobre plaintext. En búsquedas de base de datos, en texto plano es O(log n), pero si buscas con una clave cifrada pasa a O(n). Por eso, una búsqueda de Google totalmente homomórfica es básicamente inviable. Pero la inferencia DNN totalmente homomórfica podría ser diferente
Incluso sin bootstrapping, FHE no puede ser tan rápida como las operaciones en texto plano. El ciphertext es unas 1000 veces más grande que el plaintext. Eso significa que se necesita mucho más ancho de banda de memoria y mucho más cómputo. Esa brecha no se puede cerrar
Me pregunto si, incluso con un costo de cómputo 1000 veces mayor, no habrá un segmento específico que realmente quiera privacidad verificable. No sería tan grande como Dropbox, pero imagino que sí hay cierto mercado
Recuerdo la época en la que todo eran tarjetas de expansión PCIE. Las GPU también eran así, y había aceleradores especializados como los coprocesadores matemáticos. Hoy están integrados en hardware de propósito general, así que son más baratos y convenientes, pero no pueden igualar a chips de silicio optimizados para funciones específicas. Por eso sostengo que deberíamos usar tarjetas dedicadas para AI/ML aparte de las basadas en GPU. La arquitectura se superpone en parte, pero una tarjeta de AI basada en GPU termina aceptando desventajas en muchos aspectos. Creo que el verdadero acelerador de AI es hardware dedicado que entra en los sockets SXM más recientes. Pero los sockets SXM solo están en servidores y tampoco son baratos
Reconozco el boom de LLM, pero me pregunto si de verdad no habrá otros usos interesantes para FHE. Por ejemplo, podría imaginarse alojar en un servidor algoritmos de trading que no requieren alta velocidad usando FHE para garantizar seguridad
FHE es importante porque hoy existen casos en los que las empresas, bajo presión del gobierno, tienen que romper por la fuerza el cifrado de ciertos objetivos. FHE permite que una empresa pueda decir abiertamente: "nosotros jamás podemos ver el plaintext". En el rol de carrier de red esto ya es parcialmente posible con E2E encryption y similares, pero cuando los datos deben procesarse en estado plano todavía no lo es. Creo que la privacidad es un derecho humano básico. El poder del gobierno debería operar de forma muy limitada sobre actividades democráticas como votar, el arte, la prensa y la expresión
Aunque FHE permita cómputo arbitrario, la mayoría de los servicios se usan porque entregan ciertos datos concretos. Si Google quisiera garantizar seguridad sobre mi query, tendría que cifrar todo el índice de búsqueda, y eso no es realista. Incluso desde el punto de vista del negocio, fuera de unos poquísimos sectores de alta confianza y alto riesgo, casi no hay incentivos para adoptar servicios basados en FHE
Hasta donde sé, solo hace falta cifrar los datos sensibles (por ejemplo, mis transacciones bancarias). La función que se quiere computar no tiene por qué cifrarse; puede usarse en combinación con datos públicos
Al final, para las grandes empresas no hay motivación para adoptar FHE por costumbre, porque su fuente de ingresos depende de poder mirar directamente los datos o queries del usuario. En banca y finanzas puede sonar cool, pero fuera de ahí no está claro cuándo se adoptará
Lo de los incentivos es cierto. Pero la primera parte no. Las consultas privadas (lookup) sobre bases de datos en texto plano ya son posibles desde hace años. Eso sí, requiere un preprocesamiento bastante complejo del DB en texto plano, o en el peor de los casos escanear linealmente toda la DB
Se presenta spiralwiki.com como ejemplo de implementación de motor de búsqueda FHE completamente privado, donde el servidor no puede saber en absoluto qué artículo de Wikipedia está leyendo el usuario spiralwiki.com
Desde la "perspectiva del cliente", seguramente sí hay gente dispuesta a pagar por servicios que protejan perfectamente sus datos, como FHE, pero en la práctica serían carísimos y tendrían poquísimos suscriptores. Si haces las cuentas suponiendo costos de cómputo decenas de veces mayores que los actuales, incluso si un reemplazo de Google centrado en privacidad costara US$100 al año, sería difícil atraer a muchos usuarios. A medida que suba el costo, habrá aún menos suscriptores. Existen alternativas como Tor que, aunque no son perfectas, ofrecen bastante protección gratis. No es que HE no sirva; es que solo una minoría muy pequeña estaría dispuesta a pagar ese costo
Se menciona la idea de que internet podría pasar de que "la vigilancia sea lo predeterminado" a que "la privacidad sea lo predeterminado". Yo también llevo mucho tiempo difundiendo tecnologías de privacidad, incluso creando firmas digitales. Pero hay que mirar la realidad: Hacker News o Facebook tienen en sus manos la identidad de todo el mundo. Porque es demasiado fácil y rentable. FHE también es una "tecnología que la gente quiere, pero que en la práctica no se usa de forma rápida y generalizada". En la mayoría de los casos, el enfoque existente se considera suficientemente bueno por la carga de complejidad y el overhead operativo
Cuando ponía al final de mis correos algo como una firma digital, la reacción era poco más que "¿y eso qué es?". Me pregunto si alguien ha tenido experiencia convenciendo a usuarios comunes de sumarse al cifrado del lado del cliente
Se opina que, cuando FHE y AI se combinen, AI podría absorber parte de la carga de complejidad y eso tal vez se convierta en una combinación ganadora que sí logre adopción masiva
En la práctica, no creo que las empresas tengan razones para adoptar una solución tipo servicio FHE que use un millón de veces más cómputo, sea más difícil de depurar y además impida analizar patrones de uso
Empezar la discusión con el caso de Google puede inducir a error. Normalmente, cuando alguien oye "Google", piensa en "búsqueda web", pero el FHE que describe el documento podría no encajar con ese contexto porque requiere que toda la entrada esté cifrada con una sola clave. El índice de búsqueda de Google ocupa varios TB, y cifrar todo eso con una clave específica parece inviable. En otras palabras, FHE solo sirve cuando el usuario controla toda la entrada. La referencia a Google genera confusión
En casos como CallerID de Apple, no parece imprescindible cifrar toda la base de datos por usuario Investigación de Apple sobre cifrado homomórfico / Búsqueda privada de Apple
Un servicio homomórfico ni siquiera necesita conocer de antemano la clave de cifrado. Ese es justamente el punto. Se introduce un ejemplo de cifrado muy simple en el que se puede obtener el resultado de sumar ciphertexts sin especificar la clave. Si se usan cifrados más potentes que soporten operaciones más complejas, se puede implementar una variedad enorme de funciones
Cuando se dice Google no solo se piensa en búsqueda, también hay muchos servicios relacionados con datos personales como Gmail o Google docs. Quien solo piense en búsqueda probablemente ni siquiera leería el artículo relacionado
Creo que FHE no se incorporará tan fácilmente de inmediato al cómputo general ni a los servicios de internet. Harán falta, como mínimo, muchas generaciones más de la ley de Moore. Pero ya podría estar empezando a brillar en áreas donde la complejidad es baja pero la seguridad y la confianza son críticas, como smart contracts, finanzas y salud. Se considera que recientemente, gracias a Moore's law y a la optimización de software, la curva empezó a inclinarse hacia la practicidad. Se menciona como ejemplo el trabajo de Zama en hardware/Devtools
Ya se desarrolló un git con E2EE. Le pregunté a quien lo hizo si podía resolver requisitos del lado del servidor como ramas protected o impedir force push, pero si el cliente es malicioso no había una contramedida clara. Me pregunto si esto algún día evolucionará hacia un Github con E2EE Hilo relacionado en Hacker News
Cuando escucho el discurso de que la velocidad de FHE va a seguir mejorando, me viene a la mente un viejo problema matemático sobre velocidad promedio. Por ejemplo, si recorres 1 milla cuesta arriba a 15 mph y luego 1 milla cuesta abajo, ¿qué tan rápido tendrías que ir bajando para que el promedio total de 2 millas sea 30 mph? La velocidad de mejora pasada no garantiza las posibilidades futuras. No es un límite físico, sino algorítmico
¿Y si la bajada fuera un acantilado? Si calculas una velocidad terminal del auto de unas 200-300 mph, en teoría podría ser posible cubrir 1 milla en caída libre en unos 15 segundos. Como para promediar 30 mph en 2 millas se necesitan 4 minutos, habría que ajustar también apropiadamente la velocidad en la subida al tiempo restante, aunque en la práctica sería imposible por muchas variables
Si se calcula con rigor, basta con ir a 41 mph cuesta abajo para que el promedio total sea 30 mph. Si supones que en la pregunta intervienen redondeos numéricos o error de medición, sale ese resultado