El choque de fondo: un servidor ciego no puede ayudarte

Hasta aquí el recorrido ha construido un sistema donde el dato vive en el cliente, converge sin árbitro y viaja por una red que no hace falta que sea de confianza. Queda una promesa que casi todo el mundo da por hecha y que nadie ha pagado todavía: que el servidor por el que pasan los cambios no pueda leerlos. Añadir cifrado extremo a extremo suena a una capa más, una llamada a cifrar antes de enviar y otra a descifrar al recibir, y ese es exactamente el malentendido que este nivel viene a deshacer. Cifrar no es una capa: es una redistribución del trabajo. Un servidor que no puede leer no puede fusionar dos versiones, no puede comprimir por diferencia, no puede construir un índice de búsqueda, no puede validar lo que le mandan y no puede decidir quién ganó. Todo eso lo hacía alguien, y a partir del momento en que se cifra lo tiene que hacer el cliente o no lo hace nadie. Esta lección enumera con precisión qué se pierde, por qué se pierde y qué queda en pie, porque las cuatro lecciones siguientes son consecuencias de este reparto.

Las cinco cosas que hacía el servidor y deja de hacer

Conviene inventariar el trabajo del servidor de un motor de sincronización antes de quitarle la vista, porque la lista es más larga de lo que la palabra servidor sugiere. La primera función es fusionar: recibir cambios de varios clientes y producir un estado combinado, ya sea aplicando una transformación operacional o simplemente ordenando y reescribiendo. La segunda es compactar: guardar millones de operaciones pequeñas cuesta, y todo motor serio las agrupa periódicamente en instantáneas y las comprime por diferencia contra lo que ya tenía. La tercera es indexar: la búsqueda de texto completo, los filtros, los agregados y las vistas materializadas se construyen donde está el corpus entero. La cuarta es validar: rechazar una operación mal formada, un campo fuera de rango o una escritura que viola una regla de negocio. La quinta es arbitrar: cuando dos clientes proponen algo incompatible, decidir con autoridad cuál queda.

Las cinco requieren leer la carga útil. Al cifrarla, las cinco caen a la vez, y no de forma gradual sino completa: el servidor pasa de entender el noventa por ciento del contenido a entender el cero. No hay término medio útil, porque cualquier cosa que se deje en claro para que el servidor la aproveche es exactamente la cosa que el atacante aprovechará también.

flowchart LR
O[operacion en claro] --> P[cifrar en el cliente]
P --> S[el servidor recibe un sobre opaco]
S --> A[almacenar y reenviar]
S --> B[verificar firma cuota y tamano]
S --> X[fusionar comprimir indexar validar arbitrar]
style A fill:#a6e3a1,color:#11111b
style B fill:#a6e3a1,color:#11111b
style X fill:#f38ba8,color:#11111b

De las cinco, la que más sorprende es la segunda, y merece detenerse porque su imposibilidad es una propiedad deseada del cifrado y no una limitación de las bibliotecas. Un esquema de cifrado decente es indistinguible: dos textos claros parecidos, cifrados con nonces distintos, producen salidas sin ninguna correlación observable. Si un algoritmo de compresión encontrara redundancia entre dos textos cifrados, eso mismo sería una fuga: significaría que del cifrado se deduce algo del claro.

// Dos versiones casi identicas del mismo documento
const a = 'reunion del martes a las diez';
const b = 'reunion del martes a las once';

diferencia(a, b).length;             // unos pocos bytes: se comprime muy bien

// Cifradas, no comparten absolutamente nada explotable
const ca = await cifrar(clave, nonceA, a);
const cb = await cifrar(clave, nonceB, b);
diferencia(ca, cb).length;           // practicamente el tamano entero de cb

El orden inverso tampoco salva la situación. Comprimir antes de cifrar sí funciona, pero desplaza el problema: el tamaño del resultado pasa a depender del contenido, y de ahí salen las fugas por longitud que la lección siguiente examina. Y comprimir en el cliente significa que la ventana de compresión es la del cliente, no la del servidor, de modo que se pierde toda la redundancia entre documentos y entre usuarios que hacía barato el almacenamiento compartido.

Convergencia y cifrado encajan mejor de lo que parece

La buena noticia es estructural y explica por qué este nivel llega justo aquí y no antes. Una estructura que converge por construcción no necesita que nadie fusione en el centro: dos réplicas que aplican el mismo conjunto de operaciones llegan al mismo estado con independencia del orden en que las reciban. Es decir, la primera y la quinta función de la lista —fusionar y arbitrar— ya se habían mudado al cliente varios niveles atrás, por motivos que no tenían nada que ver con la privacidad. Un sistema que hubiera dependido de fusión en el servidor tendría que rehacerse entero para cifrar; uno que converge solo necesita que el servidor siga reenviando sobres.

Esa afinidad es real y conviene apreciarla, pero también acotarla, porque suele contarse de forma exagerada. Lo que encaja bien es el modelo de propagación: sobres opacos, entrega eventual, sin semántica en el centro. Lo que no encaja es el mantenimiento. Un registro de operaciones crece sin parar, y la única manera de reducirlo es compactarlo, lo cual exige leer, interpretar y descartar lo que ya no aporta. Con cifrado, esa tarea solo puede hacerla un cliente que tenga la clave y el historial completo, y un cliente así no siempre existe: el teléfono no puede sostener el corpus, el portátil lleva seis meses apagado y el servidor, que sería el candidato natural por disponibilidad y capacidad, es precisamente el que no puede.

Lo que un servidor ciego sí puede seguir haciendo

Sería un error concluir que el servidor sobra. Sigue teniendo tareas valiosas, y todas comparten una característica: operan sobre el sobre, nunca sobre la carta. Puede almacenar de forma duradera y replicada, que es justo lo que los dispositivos hacen mal. Puede entregar a quien esté desconectado ahora y aparezca dentro de un mes, que es lo que ninguna red entre pares consigue de forma fiable. Puede verificar firmas, porque las claves públicas de los autores son públicas por definición. Puede aplicar autorización de escritura por autor y por documento, porque eso son metadatos. Puede imponer cuotas, limitar tamaños y frenar abusos. Y puede ordenar por llegada, aunque ese orden no signifique nada semánticamente.

// Todo lo que el servidor puede comprobar sin abrir el sobre
function aceptar(sobre) {
  if (!verificarFirma(sobre.autor, sobre.carga, sobre.firma)) return false;
  if (!puedeEscribir(sobre.autor, sobre.documento)) return false;
  if (sobre.carga.byteLength > LIMITE_POR_OPERACION) return false;
  if (cuotaUsada(sobre.autor) > CUOTA) return false;
  return true;                    // aceptado sin haber leido un solo byte util
}

La tercera tarjeta encierra una asimetría que conviene fijar desde ahora porque decide el diseño de todo lo que viene. El control de escritura sobrevive al cifrado sin dificultad: basta con firmar y con que el resto rechace lo que no venga firmado por alguien autorizado, y esa comprobación la puede hacer tanto el servidor como cualquier par. El control de lectura, en cambio, no sobrevive: una vez que un sobre ha llegado a un dispositivo y ese dispositivo tiene la clave, ninguna política puede impedir la lectura. Esta asimetría entre escribir y leer atraviesa el nivel entero y es el motivo de que la última lección se llame problema abierto.

Dónde acaba la mudanza: el dispositivo más modesto

Todo trabajo que sale del servidor aterriza en algún cliente, y el presupuesto real del sistema no lo fija el portátil del programador sino el teléfono de gama media del usuario que menos aguanta. Conviene hacer las cuentas antes de prometer nada. La búsqueda de texto completo obliga a tener el corpus descifrado localmente, o al menos un índice construido en local, lo cual descarta de golpe el patrón de cliente ligero sobre un corpus grande. Los agregados y los informes se calculan en el dispositivo, con la memoria y la batería del dispositivo. La compactación pide historial completo y tiempo de proceso. Y la carga inicial de un usuario nuevo deja de poder servirse como una instantánea preparada por el servidor, porque el servidor no puede prepararla: hay que entregar el registro y dejar que el cliente lo reconstruya.

Las mitigaciones existen y todas son parciales. Se puede mantener un índice cifrado con esquemas de búsqueda sobre cifrado, a cambio de fugas de patrón de acceso bien documentadas. Se puede nombrar a un cliente de confianza permanente —un ordenador que siempre está encendido, propiedad del usuario o del equipo— que asuma el papel del servidor sin serlo. Se puede segmentar el corpus para que cada dispositivo cargue solo la parte que le toca. Ninguna es gratuita, y la elección entre ellas es una decisión de producto tanto como de ingeniería.