Lo que el servidor ve de todos modos: la forma del tráfico

La lección anterior dejó al servidor sin poder leer la carta. Esta se ocupa de todo lo que sigue escrito en el sobre, que resulta ser mucho más de lo que la intuición sugiere y que casi nunca aparece en la promesa comercial de un producto cifrado. Un servidor que recibe operaciones opacas conoce su tamaño exacto, el instante en que llegan, el dispositivo que las firmó, el documento al que van dirigidas y el conjunto de destinatarios a los que hay que reenviarlas. Con esos cuatro datos, repetidos durante meses, se reconstruye el organigrama de una empresa, el horario y la zona horaria de cada persona, qué proyectos existen, quién trabaja con quién, cuándo se intensifica la actividad sobre un documento concreto y qué días alguien estuvo enfermo. Nada de eso requiere romper el cifrado, porque nada de eso estaba cifrado. Esta lección enumera los canales que quedan abiertos, las mitigaciones reales con su precio y, sobre todo, la formulación honesta de lo que se le puede prometer a un usuario.

El sobre habla aunque la carta calle

Conviene mirar lo que un sobre necesita llevar en claro para que el sistema funcione, porque esa lista no es negociable: no es un descuido de implementación sino el mínimo que un encaminador requiere para encaminar. Hace falta un identificador de documento o de canal, porque si no el servidor no sabe a quién reenviar. Hace falta un identificador de autor o de dispositivo, porque si no no se puede verificar la firma ni aplicar cuota. Hace falta un tamaño, porque los bytes ocupan lo que ocupan. Y hace falta un instante, porque el servidor sella la llegada de todos modos aunque el cliente no mande ninguno.

// Un sobre minimo. Solo el ultimo campo esta protegido
const sobre = {
  documento: rutaDeEncaminamiento,   // sin esto el servidor no sabe a quien reenviar
  autor: idDeDispositivo,            // sin esto no hay firma verificable ni cuota
  epoca: 41,                         // en claro si el servidor debe descartar lo viejo
  bytes: carga.byteLength,           // no se puede ocultar lo que se transmite
  llegada: Date.now(),               // lo pone el servidor, lo mande el cliente o no
  carga: cifrado                     // lo unico realmente confidencial
};

La observación importante es que estos campos no se filtran de uno en uno: se filtran correlacionados y a lo largo del tiempo, y ahí es donde su poder crece de forma no lineal. Un identificador de documento aislado no dice nada; el conjunto de identificadores a los que un dispositivo se suscribe es su cartera de proyectos. Un instante aislado no dice nada; la distribución de instantes de un dispositivo durante tres semanas dibuja su jornada laboral, su zona horaria, sus fines de semana y sus vacaciones. Un tamaño aislado no dice nada; la secuencia de tamaños de una sesión de edición distingue con facilidad escribir a mano de pegar un bloque, y escribir a mano de borrar.

flowchart TB
S[servidor ciego] --> T[tamano de cada operacion]
S --> R[ritmo y horario de envio]
S --> G[quien se suscribe a que documento]
S --> C[que documentos se tocan en la misma sesion]
T --> D[perfil de actividad y de contenido]
R --> D
G --> D
C --> D
style S fill:#89b4fa,color:#11111b
style D fill:#f38ba8,color:#11111b

Los cuatro canales, ordenados por lo que revelan

El primero es la longitud. Un esquema de cifrado estándar produce un texto cifrado cuyo tamaño es el del claro más una constante conocida, de modo que la longitud viaja íntegra. En un editor colaborativo esto es especialmente elocuente porque las operaciones son diminutas y muy tipificadas: una pulsación es un tamaño, un borrado es otro, un pegado grande es otro, y adjuntar un fichero se distingue de todo lo demás sin ambigüedad. Con un catálogo de tamaños y un poco de estadística se clasifica el tipo de actividad sin descifrar nada.

El segundo es el tiempo. El ritmo de envío es una firma conductual difícil de disimular: hay quien escribe en ráfagas y quien escribe continuo, hay equipos que se conectan a las nueve y hay personas que trabajan de madrugada. Además el tiempo enlaza sucesos entre sí: si un dispositivo envía y medio segundo después otros tres reciben y responden, la relación entre esos cuatro dispositivos queda registrada aunque ninguno de ellos haya declarado nada.

El tercero es el grafo social, y es el más valioso de los cuatro para quien observa. Un servidor de sincronización tiene que saber a quién entregar cada cambio, así que necesariamente conoce el conjunto de suscriptores de cada documento. Ese conjunto es el equipo. La unión de esos conjuntos es el organigrama. Su evolución es el registro de altas, bajas y reorganizaciones, con fecha. Ninguna de esas tres cosas está en el contenido de ningún documento, y las tres se obtienen leyendo únicamente tablas de encaminamiento.

El cuarto es la coactividad. Los documentos que un mismo dispositivo toca dentro de una misma sesión están relacionados, y la matriz de coacceso agrupa el corpus en proyectos con una fiabilidad incómoda. Es el mismo fenómeno que hace útil la minería de cestas de la compra, aplicado a identificadores opacos: los nombres no hacen falta, la estructura aparece igual.

Mitigaciones reales y lo que cuesta cada una

Cada canal tiene defensa conocida y ninguna es gratuita, así que el trabajo consiste en decidir cuánta se compra. Contra la longitud, el relleno a cubos: se redondea el tamaño de cada operación al siguiente valor de una escala fija, de modo que muchos contenidos distintos compartan tamaño. El coste es tráfico desperdiciado, y crece rápido si los cubos son anchos; en un editor donde la operación típica ocupa decenas de bytes, rellenar a un kilobyte multiplica el consumo por veinte.

// Relleno a cubos: el tamano deja de ser una lectura directa del contenido
const CUBOS = [256, 1024, 4096, 16384, 65536];

function rellenar(bytes) {
  const destino = CUBOS.find(c => c >= bytes.length) ?? potenciaSiguiente(bytes.length);
  return concatenar(bytes, ceros(destino - bytes.length));   // el receptor recorta
}

Contra el tiempo, el agrupamiento y el retardo deliberado: acumular operaciones y enviarlas en tandas a intervalos fijos, de manera que el instante de envío deje de correlacionarse con el instante de escritura. El coste es latencia, y en una herramienta colaborativa la latencia es la función. Enviar cada dos segundos ya rompe la sensación de edición compartida, y enviar cada treinta la convierte en otro producto.

// Tandas a intervalo fijo: el reloj del envio deja de ser el reloj del usuario
setInterval(() => {
  const tanda = cola.splice(0, cola.length);
  enviar(rellenar(cifrar(clave, serializar(tanda))));   // se envia siempre, aunque vaya vacia
}, INTERVALO);

Contra el grafo social, la separación de identificadores de encaminamiento respecto de los de contenido, y su rotación periódica. Un documento puede exponer al servidor una etiqueta que cambia cada época, de modo que la observación a largo plazo no enlace la actividad de hoy con la de hace un año. El coste es coordinación: todos los suscriptores tienen que saber cuál es la etiqueta vigente, y quien estuvo desconectado durante la rotación tiene que poder alcanzarla, lo cual reintroduce estado compartido justo donde se quería evitar.

Contra la coactividad, la única defensa completa es que cada documento viaje por una conexión distinta y sin identidad común, lo cual multiplica el coste de red por el número de documentos abiertos y sigue sin tapar la correlación temporal. En la práctica se acepta la fuga o se acepta el sobrecoste, y conviene decir cuál de las dos se ha elegido.

Qué se puede prometer sin mentir

La promesa correcta se escribe en dos frases y conviene ensayarla antes de que la escriba el departamento de marketing. La primera es afirmativa y fuerte: el contenido de los documentos no es legible por el servidor ni por quien controle el servidor, ni ahora ni con una orden judicial ni tras una filtración de sus discos. La segunda es la que casi nunca se escribe y es la que da credibilidad a la primera: el servidor sí conoce quién colabora con quién, sobre cuántos documentos, con qué frecuencia y desde qué franja horaria, y ese conocimiento no se elimina cifrando.

Decir solo la primera frase es una verdad que funciona como engaño, porque el usuario que la lee entiende que nadie sabe nada de él. Y para ciertos perfiles de riesgo la segunda frase es más grave que la primera: a un periodista le puede importar menos que se lea el borrador que el hecho de que quede registrado con qué fuente colabora y desde qué país lo hace. Un sistema honesto nombra esa diferencia y deja que el usuario decida si su caso cae de un lado o del otro.