- En el software local-first, se combinan el cifrado homomórfico (Homomorphic Encryption) y los CRDTs para mantener la seguridad de documentos colaborativos
- Solo con cifrado de extremo a extremo, el servidor no puede fusionar los datos, lo que genera limitaciones en la sincronización y la eficiencia de las actualizaciones
- El cifrado homomórfico es una tecnología que permite ejecutar programas para que el servidor pueda fusionar actualizaciones de CRDT sin conocer el contenido
- Sin embargo, debido a las limitaciones fundamentales del cifrado homomórfico (degradación del rendimiento, aumento de espacio y cómputo, necesidad de que el código funcione en el peor caso), existen grandes dificultades para aplicarlo en la práctica
- Se están investigando diversos enfoques para hacer coexistir los CRDTs con el cómputo seguro, y todavía se sigue buscando una solución completa
Local-first y el desafío de la colaboración segura
- En la colaboración remota, los documentos se guardan en un CRDT con un enfoque local-first y luego, mediante sincronización, se ofrece una experiencia de edición colaborativa
- Cuando existe el requisito de seguridad de que el contenido del documento nunca debe exponerse a terceros como el desarrollador de la app, el cifrado de extremo a extremo suele ser el método más utilizado
- El cifrado de extremo a extremo es simple de implementar, pero como el servidor de sincronización no puede fusionar los datos, si se trabaja de forma asíncrona durante mucho tiempo se produce una comunicación de datos ineficiente
¿Qué es el cifrado homomórfico?
- El cifrado homomórfico es un tipo especial de cifrado que permite ejecutar algoritmos directamente sobre datos cifrados
- Esto permite que el servidor de sincronización realice la fusión de actualizaciones de CRDT sin conocer el contenido de los datos
- Según el tipo de operaciones que soporta, se clasifica en parcialmente homomórfico (solo suma o multiplicación), algo homomórfico / homomórfico por niveles (ambas, pero un número limitado de veces) y totalmente homomórfico (sin restricciones)
- A medida que aumentan las operaciones, se acumula ruido en el texto cifrado y se vuelve difícil descifrarlo, por lo que se requieren técnicas avanzadas como el bootstrapping
- A nivel de bits cifrados (0/1), es posible implementar circuitos booleanos generales combinando compuertas básicas como XOR y AND
Caso real de implementación de un CRDT con cifrado homomórfico
- Con la biblioteca basada en Rust TFHE-rs, se implementó con cifrado homomórfico un CRDT representativo llamado Last Write Wins Register
- Los campos y métodos (cifrado/descifrado) de la estructura en texto plano y la estructura cifrada son casi idénticos, pero en la lógica real de fusión aparece una diferencia importante
- Como ramificaciones de ejecución como
if/else o match pueden dar pistas para descifrar el texto cifrado, en un entorno cifrado es indispensable evaluar de inmediato todas las ramas y bucles
- Las comparaciones de condiciones principales y las operaciones de fusión se procesan con operadores FheBool a nivel de bits y métodos como
select, de modo que desde fuera no sea posible detectar bajo qué condición cambió un valor
Limitaciones fundamentales del cifrado homomórfico
- Desequilibrio entre tamaño de la clave y de los datos: en el ejemplo, para 32 bytes de datos se requiere una clave de servidor de 123 MB (27 MB incluso comprimida), lo que provoca una ineficiencia de espacio grave
- Degradación del rendimiento: la operación
merge de un CRDT cifrado homomórficamente se midió en alrededor de 1 segundo, unas 2 mil millones de veces más lenta que la versión no cifrada
- Si los bucles o ramificaciones cambian según el valor de entrada, se produce exposición de información, así que siempre se deben consumir operaciones y memoria con base en el peor caso
- Por ejemplo, incluso cuando un mapa last-write-wins tiene pares key-value dispersos, hay que fusionar todas las claves rellenándolas a un tamaño fijo, lo que reduce en la práctica la escalabilidad
- La estructura del texto cifrado o el historial de cambios deben diseñarse de forma que un observador externo no pueda inferir si cambió un valor ni qué parte fue actualizada
Conclusión y perspectivas
- Los CRDTs y el cifrado homomórfico pueden combinarse de forma natural en teoría, pero en la práctica existen restricciones críticas por la eficiencia en espacio/tiempo y por la propia estructura del programa
- Por ahora no ha aparecido una solución práctica completa, pero los CRDTs también son una tecnología relativamente joven y se sigue investigando de forma constante
- Sigue existiendo la posibilidad de encontrar soluciones innovadoras para equilibrar seguridad y usabilidad en apps colaborativas local-first
1 comentarios
Comentarios de Hacker News
Es cierto que el campo del cifrado totalmente homomórfico es realmente lento e ineficiente, pero vale la pena mencionar que esta área en sí es relativamente nueva y apareció en 2009; el avance en estos últimos 15 años ha sido realmente impresionante. Los primeros esquemas de cifrado homomórfico requerían claves de varios TB/PB, y el bootstrapping (una operación esencial en cifrado homomórfico cuando aumentan mucho las operaciones de multiplicación) tomaba miles de horas. Ahora las claves rondan los 30 MB y el bootstrapping puede hacerse en menos de 0.1 segundos. Ojalá siga mejorando y llegue el día en que pueda usarse de forma práctica.
Los primeros CRDT (CRDT: Conflict-free Replicated Data Type) también eran muy poco prácticos, como WOOT, pero las bases de datos CRDT modernas ya no rinden tan por debajo de un LSM normal. Por ejemplo, los CRDT de RDX funcionan con algoritmos similares a merge sort, así que todo es O(N). En la mayoría de las implementaciones, el overhead de metadatos también está bien controlado. Ver WOOT, librdx, go-rdx.
Por la naturaleza de la arquitectura de los CRDT, no pueden evitar ser lentos, e incluso los mejores algoritmos tienen un costo estructural alto. Si además se les suma cifrado homomórfico, el nivel de dificultad sube muchísimo. Es realmente impresionante, pero me pregunto si de verdad sirve en la práctica. Como fundamento de esa afirmación, cita la explicación: "para que el servidor calcule un nuevo mapa, tiene que fusionar todas las claves una por una, y luego enviar el mapa completo a cada peer; desde la perspectiva del servidor, el mapa completo es diferente cada vez".
CRDT significa Conflict-free Replicated Data Type, un tipo de dato especial que permite sincronización distribuida sin conflictos. Ver el artículo de Wikipedia sobre CRDT.
En el artículo se menciona que el rendimiento es insuficiente, y en la práctica, al ejecutar normalmente un registro last write wins en una M4 MacBook Pro, una fusión tarda 0.52 nanosegundos, pero la versión con cifrado homomórfico tarda 1.06 segundos. Es decir, hay una diferencia de velocidad de 2 mil millones de veces. Es una cifra realmente impactante.
FHE (Full Homomorphic Encryption) es realmente lento, pero desde 2009 ha habido avances sorprendentes. Tan solo la velocidad del bootstrapping ha mejorado decenas de millones de veces. Con tfhe-rs ya se ha demostrado incluso AES-128 basado en cifrado homomórfico. Da la impresión de que cada vez es más viable introducir FHE en tiempo real para inferencia/entrenamiento de IA. Ver el repositorio de tfhe-aes-128.
No puedo estar de acuerdo con la idea de que el servidor ya no puede entender los cambios del cliente. El servidor solo envía los cambios que el usuario todavía no ha visto, y el usuario los descifra y fusiona para construir la versión más reciente del documento. El cifrado homomórfico es interesante, pero en situaciones donde se necesita un rendimiento o ancho de banda razonable, casi nunca es adecuado. Hace tiempo vi un artículo sobre computación totalmente confidencial basada en cifrado homomórfico (codificando una CPU+RAM personalizada como cifrado y procesando una instrucción por cada pulso de reloj); efectivamente funciona, pero a una velocidad de apenas 1 instrucción de CPU virtual por segundo. Si esa velocidad y ese costo te parecen aceptables, sería más sensato ejecutarlo localmente o, si eres realmente rico, comprar tu propio hardware y procesarlo en local.
Los artículos de ciencias de la computación y criptografía muchas veces están bastante alejados de la utilidad práctica; por ejemplo, hay investigaciones absurdamente irreales como reducir la complejidad de un ataque de 2^250 a 2^230. Aun así, ese tipo de trabajo tiene valor para el I+D real o para ampliar la frontera de lo posible.
Si el servidor no puede manejar el contenido directamente, no puede fusionar documentos CRDT, y cada vez tendría que recibir y reenviar el estado completo del CRDT. Si tu amigo está en línea al mismo tiempo, se pueden enviar operations y hacer merge en tiempo real, pero si no, resulta muy ineficiente.
Me pregunto si sería confiable que estudiantes ejecuten directamente en sus Chromebook código de evaluación en WASM o JS cifrado con FHE usando una combinación de JupyterLite y ottergrader. También me da curiosidad la relación entre la firma de código y el screensaver de SETI@home.
Mejor no usar THFE-rs, porque Zama exige una licencia comercial para cualquier uso que no sea prototipado, así que las condiciones de licencia son incómodas. En su lugar recomiendo las bibliotecas openFHE (C++) y lattigo (golang), ambas de uso comercial libre.
Creo que FHE es, en esencia, una herramienta inadecuada para este caso. FHE sirve para tratar datos que pertenecen a un servidor central o que este conoce. Aquí varios usuarios necesitan procesar juntos datos distribuidos, así que MPC (computación multipartita: una forma en que varios participantes realizan operaciones conjuntas, como sumar sus datos secretos) es mucho más eficiente.
No termino de entender la suposición planteada en el artículo. Entiendo los conceptos de CRDT y cifrado homomórfico, pero me pregunto por qué ambas partes tendrían que estar en línea al mismo tiempo para sincronizarse. Con un esquema asíncrono de “store-and-forward”, los datos en tránsito también pueden enviarse cifrados, así que no entiendo por qué el servidor tendría que mantener estado (encima cifrado) ni por qué habría que modificarlo como se propone.
Me parece curiosa la combinación entre la lentitud e ineficiencia de FHE y el desperdicio de espacio de almacenamiento de los CRDT.