Seguridad y modelo de amenazas
Última actualización: 2026-08-02
Relayium está diseñado para que las personas que transfieren archivos o textos temporales —no el servidor— tengan las claves. Esta página describe exactamente qué está protegido, cómo funciona y los límites de esa protección.
En resumen: en la misma red, los archivos y mensajes en tiempo real circulan directamente entre dispositivos. Entre redes, las sesiones del navegador usan un retransmisor que solo transporta texto cifrado de extremo a extremo y no posee la clave del contenido. Siempre se usan claves nuevas en cada sesión; además, un código opcional comparado fuera de banda permite detectar la interceptación de la señalización. A continuación, los detalles.
Cifrado de archivos en tiempo real del navegador (X25519 + AES-256-GCM)
Para archivos en tiempo real del navegador, cada transferencia genera un par X25519 efímero en cada dispositivo y ambos navegadores derivan una clave AES-256-GCM compartida. Cada fragmento usa un nonce único, por lo que señalización y retransmisor ven texto cifrado, no el archivo en claro. La CLI usa un protocolo directo TLS 1.3 distinto descrito más abajo.
- Las claves son efímeras y por transferencia: nada se reutiliza entre sesiones.
- La clave compartida se deriva en los dos dispositivos; nunca se envía a ningún servidor ni se almacena en él.
- El cifrado se aplica en la capa de aplicación, por encima de la propia seguridad de transporte de WebRTC, de modo que se mantiene incluso si la capa de transporte se ve comprometida.
El código de verificación (SAS): detectar un servidor malicioso
WebRTC intercambia huellas mediante el servidor de señalización, que podría intentar sustituir claves. Relayium puede mostrar por ello un SAS de 6 dígitos en ambas pantallas. Los códigos coincidentes ofrecen la comprobación más sólida solo cuando ambas personas los comparan fuera de banda. Mostrar ese código y detenerse a compararlo es una preferencia: «verificación avanzada» en la web (desactivada por omisión) y `--verify` en la CLI. Desactivarla cambia qué se muestra y qué pasos se detienen para pedir confirmación; no cambia el cifrado. El handshake de compromiso y revelación de abajo se ejecuta en cada conexión y rechaza aquella cuya revelación no coincide, las claves se siguen generando en tu dispositivo y nunca se nos envían, el retransmisor sigue transportando solo texto cifrado, y en el navegador, recibir archivos sigue preguntándote antes de guardar nada: la aplicación nativa de macOS, en cambio, escribe sin preguntar en su carpeta de destino configurada (Descargas por omisión). Esa pregunta evita escrituras no solicitadas en tu disco; no dice quién está al otro lado, algo que solo establece comparar el código.
El compromiso y posterior revelación impide que el servidor elija después una clave que colisione. La CLI usa un SAS separado derivado del intercambio de las huellas del certificado TLS fijado; también detecta algo solo si alguien lo compara de verdad fuera de banda, que es para lo que se detiene `--verify`.
- Para la garantía más sólida, activa la verificación avanzada y compara el código fuera de banda: en persona o por una llamada de voz.
- Si los dos códigos difieren, detén la transferencia: alguien podría estar interceptando la conexión.
Texto claro que el servidor no puede ver ni descifrar
Nuestros servidores están diseñados para no poder ver ni descifrar el siguiente texto claro:
En la misma red, los bytes de archivos y mensajes circulan directamente entre dispositivos. Entre redes pasan por TURN como texto cifrado, sin que el retransmisor tenga la clave. La señalización sí procesa datos de conexión y ve metadatos como IP pública, sala, horario, apodo y presencia.
- El contenido de tus archivos.
- Los nombres de tus archivos.
- El texto claro de tus mensajes.
- Tus claves de cifrado.
Cuando los archivos y textos del navegador se retransmiten (TURN)
Los archivos y textos del navegador entre redes usan TURN por diseño, no como alternativa, porque NAT y cortafuegos hacen improbable la ruta directa. Las sesiones del navegador en la misma red conectan directamente sin credenciales de retransmisión. Los archivos y textos de la CLI nunca usan TURN: son solo directos y fallan sin una ruta directa.
- El retransmisor reenvía únicamente texto cifrado: no puede leer tus archivos ni mensajes, que permanecen cifrados de extremo a extremo.
- Registramos el número de bytes retransmitidos por cuenta, para aplicar una asignación mensual de retransmisión y evitar el abuso; nunca inspeccionamos lo que se retransmite, solo el recuento de bytes.
- Nunca inspeccionamos el contenido retransmitido.
Transferencia de texto temporal
Las sesiones de texto del navegador usan el protocolo Web: los pares realizan un intercambio X25519 efímero y derivan subclaves AES-256-GCM separadas por dirección en un dominio distinto del de las claves de transferencia de archivos. Cada mensaje UTF-8 válido se autentica y cifra como una trama independiente. Entre redes, las sesiones del navegador usan TURN por diseño; el retransmisor transporta texto cifrado y no tiene la clave del mensaje. Con la verificación avanzada activada, comparar el SAS fuera de banda detecta además una interceptación de la señalización.
El texto de la CLI utiliza un protocolo distinto, exclusivamente directo, sobre TLS 1.3 con certificado fijado. No usa las tramas X25519/AES del navegador ni TURN, y falla si no puede establecerse una ruta directa. Relayium no almacena el cuerpo de los mensajes, pero cualquiera de los extremos puede copiar, registrar, capturar o conservar de otro modo el texto después de recibirlo.
- Ambas personas deben estar en línea a la vez; Relayium no proporciona entrega de texto sin conexión ni historial de mensajes en el servidor.
- Los servidores necesariamente procesan metadatos de conexión como direcciones IP, pertenencia a la sala, horario, apodo del dispositivo y presencia en sesiones del navegador, y, cuando corresponda, la asociación de la cuenta usada para crear un código de emparejamiento.
- En sesiones TURN, Relayium puede registrar el número de bytes retransmitidos para aplicar la asignación y evitar abusos, pero no inspecciona el texto en claro de los mensajes.
Enlaces de descarga almacenados: la clave nunca abandona tu navegador
El modo opcional de enlace de descarga es para cuando el destinatario no está en línea. Tu navegador cifra los archivos con AES-256-GCM antes de subir nada, y la clave de descifrado se coloca únicamente en el fragmento de la URL —la parte después del #—, que los navegadores nunca envían al servidor.
- El servidor almacena solo texto cifrado, además del tamaño del texto cifrado y marcas de tiempo para la cuota y la limpieza; nunca texto en claro, nombres de archivos ni claves.
- Cualquiera que tenga el enlace completo puede descifrar, así que trata el enlace como el archivo mismo y compártelo por un canal de confianza.
- Los enlaces pueden configurarse para que caduquen (de 1 hora hasta 14 días, según tu plan) o para que se destruyan tras la primera descarga completa.
Integridad de los archivos (SHA-256)
Más allá de la confidencialidad, se verifica la integridad de cada archivo. Cada fragmento lleva una etiqueta de autenticación AES-GCM, y en el lado receptor se comprueba de extremo a extremo un hash SHA-256 por archivo, de modo que un archivo dañado o manipulado se detecta en lugar de aceptarse en silencio.
Contra qué no protege Relayium
El cifrado de extremo a extremo protege los datos en tránsito entre dos extremos honestos. Por diseño, no puede proteger contra:
- Un dispositivo o navegador comprometido en cualquiera de los extremos: malware, una extensión de navegador hostil o alguien que lee la pantalla.
- Los metadatos necesarios: horario de la sesión, bytes retransmitidos y, para un enlace almacenado o una sesión con código, la cuenta que creó el enlace o el código.
- Un destinatario que conserva, copia o reenvía archivos o mensajes después de recibirlos.
- Compartir un enlace de descarga por un canal no fiable, ya que la clave de descifrado viaja dentro del enlace.
Compatibilidad con navegadores y sus límites
Relayium funciona en cualquier navegador moderno con WebRTC a través de HTTPS. Algunas capacidades difieren según el navegador:
- Chrome y Edge de escritorio disponen de la API File System Access y transmiten los archivos grandes directamente al disco, sin un techo de memoria práctico.
- Firefox, Safari y todos los navegadores móviles (en iOS todos los navegadores son WebKit) carecen de esa API y ensamblan el archivo en memoria en la ruta en tiempo real, por lo que la aplicación avisa por encima de unos 256 MB: una estimación deliberadamente conservadora, no un límite medido. Para archivos de ese tamaño, prefiere Chrome/Edge de escritorio, o usa el modo de enlace de descarga, cuya página de descarga además puede escribir en disco mediante un service worker.
- WebRTC requiere un contexto seguro (HTTPS); la aplicación no se conectará por HTTP simple.
Código abierto e informe de problemas
El diseño del protocolo y todo el código de cliente y servidor son públicos en GitHub, de modo que cualquiera puede auditar la criptografía, ejecutar su propio servidor o contribuir. Si encuentras un problema de seguridad, infórmalo de forma privada a través del informe de vulnerabilidades de GitHub en el repositorio, en lugar de abrir una incidencia pública.