Cifrado y verificación de Matrix en OpenClaw

Las salas cifradas de Matrix solo funcionan cuando el dispositivo del Gateway es de confianza para la cuenta que lo posee, y en Matrix la confianza es una cadena: almacenamiento de secretos, claves de firma cruzada, un dispositivo verificado y una copia de seguridad de claves de sala. OpenClaw envuelve esa cadena en un pequeño conjunto de comandos y es explícito sobre lo que demuestra cada señal de confianza. Aquí verás cómo se activa el cifrado, cómo funcionan el estado y la verificación, cómo se inicializa o repara la firma cruzada, cómo se restauran o restablecen las copias de seguridad, los comandos SAS y las notas operativas.

Activación y estado

• En las salas cifradas, los eventos de imagen salientes usan un archivo de miniatura cifrado para que las vistas previas se cifren junto con el adjunto, sin configuración, ya que el plugin detecta el estado de cifrado de la sala; todos los comandos de Matrix aceptan flags de salida detallada, JSON y cuenta, y la salida es concisa por defecto.
• El comando de configuración del cifrado inicializa el almacenamiento de secretos y la firma cruzada y crea una copia de seguridad de claves de sala si hace falta, con la clave de recuperación leída desde stdin para que nunca aparezca en los argumentos del proceso, y con un flag deliberado para descartar la identidad de firma cruzada actual; una cuenta nueva puede activar el cifrado al crearse, y ambas vías terminan sus operaciones de cliente antes de guardar la configuración para que un Gateway en ejecución pueda recargarla después, mientras que una inicialización fallida guarda igualmente el ajuste e indica los siguientes pasos.
• El estado de verificación informa de tres señales independientes: de confianza local, solo para este cliente; verificado por firma cruzada, según el SDK; y firmado por el propietario, un diagnóstico de que el dispositivo lleva tu clave de autofirma. Un flag para incluir la clave de recuperación solo confirma en la salida de texto que hay una clave en bruto disponible y te remite al JSON, que entonces debes mantener en privado.
• Verificar el dispositivo con una clave de recuperación por stdin informa de tres estados, clave aceptada, copia de seguridad utilizable y dispositivo verificado por el propietario, y termina con un código distinto de cero cuando la confianza plena en la identidad está incompleta, aunque la clave haya desbloqueado material de la copia de seguridad; terminar implica entonces una autoverificación desde otro cliente, que el comando de autoverificación espera hasta que la firma cruzada informa de verificado.

“Verified by owner” solo es “yes” cuando “Cross-signing verified” es “yes”; la confianza local o una firma del propietario por sí solas no bastan.

Reparación y copia de seguridad

El comando de inicialización es la vía de reparación y configuración para las cuentas cifradas: inicializa el almacenamiento de secretos reutilizando una clave de recuperación existente cuando es posible, inicializa la firma cruzada y sube las claves públicas que faltan, marca y firma de forma cruzada el dispositivo actual, y crea una copia de seguridad de claves de sala en el servidor si no existe ninguna; cuando el homeserver exige autenticación interactiva para subir claves, OpenClaw prueba sin autenticación, luego la etapa de inicio de sesión dummy y luego el inicio de sesión con contraseña, que necesita la contraseña de la cuenta en la configuración. El estado de la copia de seguridad muestra si existe una copia en el servidor y si este dispositivo puede descifrarla, la restauración importa las claves de sala respaldadas al almacén criptográfico local, y una edición cuyo historial no está totalmente descifrado se arregla restaurando las claves que faltan y reintentando, o enviando un mensaje nuevo cuando las claves ya no existen. Un restablecimiento de la copia de seguridad reemplaza una copia rota por una base nueva, aceptando la pérdida del historial irrecuperable y, opcionalmente, recreando el almacenamiento de secretos, y se añade un flag de rotación solo cuando la clave de recuperación anterior debe dejar de desbloquear la nueva base.

SAS, cuentas, arranque

• El comando verify list muestra las solicitudes pendientes, y verify request envía una, ya sea una autoverificación con el flag de usuario propio, para aceptarla en otro cliente del mismo usuario, o a un usuario, dispositivo o sala concretos; los comandos de ciclo de vida de más bajo nivel aceptan una solicitud, inician el flujo SAS, muestran los emoji o los decimales, confirman o rechazan la coincidencia y cancelan con un motivo y un código, y todos admiten indicaciones de seguimiento por mensaje directo cuando están anclados a una sala directa.
• Sin un flag de cuenta, los comandos usan la cuenta predeterminada implícita; con varias cuentas con nombre y ninguna predeterminada se niegan a adivinar, y una cuenta con nombre sin cifrado informa de su propia clave de configuración. Con el cifrado activado, la verificación al arrancar es if-unverified por defecto: un dispositivo sin verificar solicita la autoverificación en otro cliente, omitiendo duplicados durante un periodo de espera de veinticuatro horas que se puede ajustar o desactivar, y el arranque también ejecuta una pasada de inicialización conservadora que intenta una reparación protegida sin contraseña y no resulta fatal cuando se requiere autenticación con contraseña.
• Los avisos del ciclo de vida de la verificación (solicitud, listo con indicaciones sobre los emoji, inicio, finalización y detalles de SAS) se publican en la sala estricta de verificación por mensaje directo como avisos y nunca llegan al pipeline del agente; las solicitudes entrantes desde otro cliente se registran y se aceptan automáticamente, y la autoverificación inicia el flujo SAS automáticamente y confirma su propio lado mientras tú sigues comparando en tu cliente. Un dispositivo que ya no aparece en el homeserver se sustituye añadiendo de nuevo la cuenta con un inicio de sesión con contraseña o un token de acceso nuevo, los dispositivos obsoletos se listan y se eliminan con los comandos devices, y el estado criptográfico vive bajo el directorio de estado en raíces por cuenta indexadas por homeserver, usuario y hash del token, donde una única raíz más antigua es la continuidad normal de la rotación, pero varias raíces con datos deben inspeccionarse y archivarse en lugar de borrarse.

OpenClaw en Matrix es el artículo del canal que este amplía, y cuentas y homeservers de Matrix en OpenClaw, la página complementaria sobre configuraciones con varias cuentas, homeservers privados y formatos de destino.

En Diali

Matrix está en la lista de canales conectables de Diali, junto a WhatsApp, Telegram, Discord, Slack, Mattermost, SMS y voz: la cuenta del homeserver y la lista de salas permitidas son tuyas, el Gateway es nuestro. Conecta tu primer canal en cinco minutos explica cómo se vinculan, y la seguridad en Diali, el límite que se aplica a cada uno.

Lo que aporta la regla de confianza

Exigir la verificación por firma cruzada en lugar de la confianza local significa que el propio Gateway no puede dar por bueno un dispositivo robado o reproducido; solo el propietario de la cuenta, desde otro cliente, puede completar la cadena. OpenClaw alojado en Diali es el asistente y OpenClaw doctor, el comando que muestra los problemas del estado criptográfico junto con el resto de la configuración.

• Configurar, verificar, inicializar, respaldar: cuatro comandos.
• Claves de recuperación por stdin, nunca en la línea de comandos.
• Solo cuenta la firma cruzada; termina desde otro cliente.