Cifrado de extremo a extremo, con las claves en tus propios dispositivos

Hay un secreto en la raíz de tu cuenta, y se crea en un dispositivo — no lo emite un servidor. Todo lo demás se deriva de él mediante un árbol de claves: una raíz HMAC-SHA-512 y luego un paso HMAC por cada elemento etiquetado de la ruta. El par de claves que abre las claves de sesión selladas sale de ese árbol bajo la etiqueta "content", y también sale de ahí una clave distinta para cada otro tipo de blob almacenado, de modo que ninguna clave hace dos trabajos.

Por eso un navegador recién estrenado puede iniciar sesión en tu cuenta y aun así no enseñarte nada de la semana pasada. Iniciar sesión demuestra al relay quién eres. Leer una sesión antigua necesita la clave, y la clave no está en el relay para que la envíe. Restaurar el dispositivo es el paso que la mueve — desde un dispositivo que ya la tiene, o desde la clave secreta que guardaste.

También significa que el caso de pérdida es real y merece decirse una vez: si todos los dispositivos con la sesión iniciada han desaparecido y la clave secreta ha desaparecido con ellos, las sesiones cifradas no las podemos recuperar ni nosotros ni nadie. Un relay que pudiera devolverlas sería un relay que podría leerlas.

Añadir un dispositivo es el momento en que se mueve material de claves, así que es el momento que merece la pena entender. Escanear el código QR levanta una solicitud, y eso es todo lo que hace: la aprobación ocurre en un dispositivo que ya tiene la sesión iniciada y, cuando las dos pantallas muestran un código de confirmación corto, se espera que los compares antes de aprobar.

Lo que hace realmente la aprobación es sellar la clave de contenido con la clave pública del dispositivo que la pidió, en un sobre que lleva una clave de emisor efímera y un nonce nuevo. Ese sobre viaja por el relay como todo lo demás. Conectar una terminal añade una atadura más encima: el payload se autentica contra un secreto de emparejamiento que viajó dentro del código QR, no a través del servidor, así que un relay que cambiara el payload no podría producir una etiqueta que cuadrara.

Todo lo de arriba describe el valor por defecto, y ese valor por defecto no es una sugerencia de la que el cliente pueda disuadir al servidor. Un relay recién instalado está configurado para exigir almacenamiento cifrado de extremo a extremo: una escritura en claro se rechaza con un error de política en vez de aceptarse en silencio. Los clientes leen la política del propio endpoint de features del servidor antes de crear una sesión, así que el modo en el que está una sesión se acordó antes de su primer mensaje.

Quien opera un servidor tiene otros dos ajustes disponibles. Uno puede permitir que una cuenta elija, de modo que las sesiones cifradas y en claro coexistan en el mismo relay — hace falta tanto la política opcional como el permiso de exclusión, y ese permiso está apagado salvo que el operador lo encienda. El otro exige texto en claro, para organizaciones que gestionan el cifrado en la capa de infraestructura y necesitan que el servidor pueda leer y procesar el contenido de las sesiones. Ese último es un intercambio real y merece decirse sin suavizarlo: en una sesión en claro el servidor puede leer la transcripción. Ese es el sentido del ajuste.

El modo queda fijado por sesión en el momento de crearla, así que una sesión nunca es mitad y mitad, y cambiar el modo de una cuenta cambia lo que pasa con las sesiones nuevas en lugar de alcanzar hacia atrás a las antiguas. Nada se descifra retroactivamente, y nada se cifra retroactivamente tampoco.

Las variables que fijan las tres, las opciones de cifrado en reposo que hay debajo y los controles de identidad que las rodean son la mitad del operador, y viven en la página de autoalojamiento para equipos.

Una notificación push es lo único que se sale del modelo, porque tiene que llegar a un teléfono que no tiene nada abierto. La respuesta de Happier es que las envía tu propio ordenador. El servidor almacena tus tokens de push; la CLI de tu propio ordenador los lee de vuelta y envía la notificación ella misma, lo que mantiene al relay fuera de un camino cuyo contenido, si no, habría que contarle.

Lo que lleva el payload es deliberadamente escaso: el tipo de herramienta o de solicitud, y una pista corta donde ayude — un archivo como src/file.ts, el nombre de un comando, un recuento como "3 preguntas". La entrada bruta de la herramienta no se mete ahí. Lo justo para decidir si coger el teléfono, en una pantalla que puede leer cualquiera que esté detrás de ti.

Todo esto se sostiene en un relay que no ejecutas tú. La razón para ejecutar el tuyo es la fila de arriba sobre identificadores y forma: el cifrado no oculta quién habla con quién, ni con qué frecuencia, y en tu propio relay ese registro también es tuyo. Un comando pone el relay en hardware tuyo, y el camino pasa a ser tu dispositivo, tu relay, tu ordenador, sin nada dentro que no hayas desplegado tú.

En esta página no hay ninguna certificación porque no hay ninguna que reportar, y una página de seguridad que insinúa un cumplimiento que no tiene es peor que una que no lo menciona. Lo que hay en su lugar es el código a partir del cual se escribió cada frase de arriba, con licencia MIT y legible antes de ejecutarlo: las primitivas en packages/protocol/src/crypto, el cifrado de sesión en apps/cli/src/api/encryption.ts, la política de almacenamiento que el servidor aplica en su endpoint de features, y el esquema que muestra exactamente qué columnas están en claro.

Esa es también la respuesta honesta a cómo deberías tratar esta página: como un mapa de dónde mirar, no como una promesa que aceptar por fe. Lee los cuatro archivos, o ejecuta el relay tú mismo y lee lo que anuncia a sus clientes.

La referencia del modelo de cifrado cubre el mismo terreno como procedimiento — qué te pide una restauración, qué significa cada modo de almacenamiento para una cuenta, a qué flujo recurrir cuando un dispositivo aún no puede leer una sesión.