Cómo Relayium cifra tus archivos de extremo a extremo

Última actualización: 2026-08-06

«¿Es seguro Relayium?» es una pregunta justa — toda herramienta de transferencia de archivos afirma ser privada. Esta página recorre exactamente cómo Relayium mantiene privados los archivos, en lenguaje sencillo, para que puedas juzgar la afirmación en lugar de creértela a ciegas.

Hay dos esquemas de cifrado distintos en juego, porque hay dos situaciones distintas: enviar un archivo en vivo a alguien que está en línea ahora mismo, y dejar un enlace de descarga para que alguien lo recoja más tarde. Ambos dejan al servidor fuera de tu archivo, pero llegan ahí por caminos diferentes — y vale la pena saber cuál se aplica en cada caso.

Transferencias en vivo: dos dispositivos acuerdan un secreto que el servidor nunca ve

Cuando envías un archivo en tiempo real —ambas personas en línea, de navegador a navegador— Relayium empieza haciendo que cada dispositivo genere un nuevo par de claves con X25519, el mismo intercambio de claves de curva elíptica que se usa en la mensajería segura moderna (técnicamente, crypto_kx de libsodium). Cada dispositivo se guarda su clave privada para sí y envía solo su clave pública al otro lado.

A partir de esas dos claves públicas, cada dispositivo calcula de forma independiente el mismo secreto compartido — un proceso que funciona precisamente por cómo está construido el intercambio de claves de curva elíptica, no porque el secreto se haya enviado a ningún sitio. Ese secreto compartido se convierte en una clave AES-256-GCM que existe solo dentro de los dos navegadores. Cada bloque del archivo se sella con esa clave y un nonce único antes siquiera de salir del dispositivo del remitente, así que todo lo que cruza la red —incluido el servidor de señalización que ayudó a los dos navegadores a encontrarse— solo ve texto cifrado.

Se genera un nuevo par de claves para cada transferencia — nada se reutiliza entre sesiones.
La clave AES-256-GCM compartida se deriva de forma independiente en cada dispositivo; nunca se transmite a ningún sitio, incluidos los propios servidores de Relayium.
El cifrado ocurre en la capa de aplicación, por encima de la propia seguridad de transporte de WebRTC, así que se mantiene incluso si esa capa de transporte llegara a verse comprometida.

El código de 6 dígitos que detecta a un servidor deshonesto

Lo que necesitas para hacer esta comparación

Los dos dispositivos delante de ti, o alguien que esté ahora mismo delante del suyo.
Un canal que no sea esta transferencia: una llamada, o la habitación en la que estáis los dos. Pegar el código en la misma conversación que te preocupa no demuestra nada.
Diez segundos. Ese es todo el coste de la única comprobación que descubre a un servidor deshonesto.

Hay una sutileza que conviene reconocer con honestidad. El cifrado propio de WebRTC (DTLS) intercambia las huellas de las claves a través del servidor de señalización que presenta los dos dispositivos entre sí. Si ese servidor fuera deshonesto, podría en teoría situarse en medio y sustituir sus propias claves — un clásico ataque de intermediario — sin que ninguno de los dos navegadores lo notara de inmediato.

Relayium cierra esa brecha con un breve código de verificación. Ambos dispositivos derivan el mismo Short Authentication String (SAS) de 6 dígitos a partir de sus dos claves públicas y pueden mostrarlo en pantalla. Mostrarlo y detenerse a compararlo es la «verificación avanzada», desactivada por omisión: una transferencia predeterminada no muestra ningún código. Todo lo demás que se describe aquí sigue aplicándose a cada transferencia: las claves nuevas, el cifrado, el handshake de comprometer-y-luego-revelar y la autenticación de cada fragmento. Lo que no tiene una transferencia predeterminada es esta comprobación en sí — detectar una clave sustituida, o a un desconocido al otro lado, exige activar la verificación avanzada y que las dos personas comparen realmente el código por otro canal. Si los códigos coinciden, las claves públicas no se sustituyeron: el servidor de señalización o de retransmisión no suplantó a ninguno de los extremos ni terminó el cifrado de extremo a extremo de la capa de aplicación. Esto no significa que no hubiera ningún servidor en la ruta de red — el texto cifrado entre redes aún puede pasar por TURN por diseño. Pero un código simple de 6 dígitos son solo unos 20 bits, que en principio un atacante bien situado podría intentar forzar por fuerza bruta hasta hacerlo coincidir tras ver ambas claves reales. Para evitarlo, Relayium usa un handshake de comprometer-y-luego-revelar: cada lado envía primero un hash que lo compromete con su clave, y solo revela la clave real después de recibir el compromiso del otro lado. Ese orden significa que un servidor malicioso tiene que comprometerse a ciegas con una clave falsa, antes de haber visto la real — no puede elegir después una clave que colisione, así que el código corto sigue siendo fiable.

Inicia una transferencia entre los dos dispositivos y espera a que aparezca un código de verificación en cada pantalla.
```
https://relayium.com/
```
Lee uno de ellos en voz alta, dígito a dígito, por el canal aparte: sin copiarlo en la aplicación ni en el mismo hilo de chat.
Compara los seis dígitos. Coincidir en parte es no coincidir.
Acepta solo si son iguales. Si difieren, rechaza y averigua en qué máquina está realmente la otra persona antes de volver a intentarlo.
En la CLI, haz que la comparación sea bloqueante en vez de opcional: --verify detiene la transferencia en ese punto y espera tu confirmación, así que no se mueve ni un byte hasta que alguien haya mirado de verdad.
```
relayium send --verify ./report.pdf
```

Qué demuestra una comparación que coincide, y qué no

Dos pantallas con los mismos seis dígitos significan que las huellas de certificado fijadas por ambos extremos coinciden, así que el rendezvous no sustituyó ningún extremo ni suplantó a ninguna de las dos partes. Ese es exactamente el ataque del que trata esta sección.

Autentica los dos extremos. No demuestra nada sobre cada salto de red intermedio, y no demuestra absolutamente nada si nadie la compara: para eso existe --verify.

Para la garantía más fuerte, activa la verificación avanzada y luego lee el código en voz alta en una llamada o compáralo en persona, no solo a ojo en dos pantallas una al lado de la otra.
Si los dos códigos no coinciden, detente — trátalo como una señal de que alguien podría estar interceptando la conexión.

Asegurarse de que lo que llega es exactamente lo que se envió

El cifrado protege el secreto, pero no prueba automáticamente que nada se haya corrompido o manipulado por el camino. Relayium lo comprueba por separado: cada bloque lleva su propia etiqueta de autenticación AES-GCM, así que un bloque modificado no logra descifrarse en absoluto. Además, a medida que se envía cada archivo, ambos lados calculan un hash SHA-256 continuo sobre su contenido en claro; cuando el archivo termina, el hash del remitente se compara con el del destinatario. Si coinciden, lo que aterrizó en el disco es byte por byte lo que se envió — si no, el archivo se marca en lugar de aceptarse en silencio.

Enlaces almacenados: una clave diferente, generada una sola vez, guardada solo en el enlace

La transferencia en tiempo real necesita a ambas personas en línea al mismo tiempo. Cuando eso no es posible, Relayium ofrece en su lugar un enlace de descarga almacenado — y este usa un mecanismo genuinamente distinto, que conviene no confundir con el de tiempo real anterior.

Aquí no hay intercambio de claves, porque todavía no hay un segundo dispositivo con el que intercambiar. En su lugar, tu navegador genera una única clave AES-256-GCM aleatoria y la usa para cifrar los archivos antes de que se suba nada. Esa clave no se envía en absoluto al servidor — se añade al enlace de descarga tras un carácter #, en lo que se llama el fragmento de la URL, una parte de la dirección que los navegadores deliberadamente nunca transmiten a un servidor. El servidor acaba almacenando solo texto cifrado que no tiene forma de descifrar, además de datos administrativos como el tamaño del texto cifrado y una marca de tiempo de caducidad. Cualquiera que abra el enlace completo —fragmento incluido— puede descifrar el archivo localmente en su navegador; cualquiera sin él solo ve un bloque opaco en el servidor. Esa es la parte de conocimiento cero: el servidor guarda el archivo cifrado sin llegar nunca a tener los medios para leerlo.

Crear un enlace almacenado requiere que el remitente inicie sesión; abrir uno para descargar no lo requiere nunca.
Los enlaces pueden configurarse para caducar tras 1 hora, 1 día, 3 días, 7 días o hasta 14 días según tu plan, o para destruirse tras la primera descarga completada.
Trata el enlace completo como el propio archivo — cualquiera que lo tenga puede descifrarlo, así que compártelo como compartirías el archivo.

Lo que el servidor puede ver — y lo que no

Vale la pena precisar exactamente dónde se sitúa el servidor en todo esto, porque «cifrado de extremo a extremo» es una afirmación fácil de hacer y más difícil de precisar. En modo tiempo real en la misma red, el archivo en sí nunca toca los servidores de Relayium — se transmite directamente entre los dos navegadores. El trabajo del servidor de señalización se limita a retransmitir los mensajes de establecimiento de conexión (la información técnica SDP/ICE que WebRTC necesita para establecer un enlace directo) para que los dos dispositivos puedan encontrarse; nunca ve el contenido de los archivos, los nombres de archivo ni las claves.

Entre redes —donde los NAT o cortafuegos restrictivos suelen descartar cualquier ruta directa— el flujo cifrado pasa por un servidor retransmisor TURN. El retransmisor solo reenvía texto cifrado; no tiene ninguna clave y no puede descifrar lo que pasa a través de él. Lo que sí hace es contabilizar los bytes que retransmite contra la asignación mensual de retransmisión de la cuenta que envía, puramente para medición y prevención de abusos — sin inspeccionar nunca lo que hay dentro.

Cuando la comparación sale mal

Tres desenlaces, y solo el primero es una urgencia. Saber cuál tienes delante ya es la mayor parte del valor.

Qué ves, qué comprobar, qué significa

Las dos pantallas muestran códigos distintos.

https://relayium.com/   # the two screens show different verification codes

Para y no envíes el archivo. Que los códigos difieran significa que los dos extremos fijaron huellas de certificado distintas, así que el otro lado no es la máquina que crees. Confirma por un canal aparte en qué dispositivo está la otra persona y empieza de nuevo. Volver a lanzarlo con --verify hace que la transferencia espere en esa comparación en lugar de dejarla a tu atención.

No ha aparecido ningún código de verificación.

https://relayium.com/   # no verification code on screen yet

El código se deriva de una conexión, así que existe en cuanto los dos extremos se han conectado. Antes de eso no hay nada que comparar, y una transferencia que nunca conecta es un problema distinto de una cuyos códigos discrepan.

Comparaste los códigos pegando uno en el chat que ya estabais usando.

relayium send --verify ./report.pdf   # holds the transfer at the comparison

Eso no comprueba lo que querías comprobar. Si ese canal es justo lo que te preocupa, un atacante capaz de alterar la transferencia también puede alterar el código pegado. Léelo en voz alta, o usa un canal que falle de otra manera que el que estás revisando.

Preguntas frecuentes

¿Puede Relayium leer mis archivos?

No. En modo tiempo real, la clave de cifrado se deriva de forma independiente en ambos dispositivos y nunca los abandona — los servidores de Relayium nunca la ven, ni tampoco el contenido de los archivos. Para los enlaces almacenados, la clave vive solo en el fragmento de la URL, que los navegadores nunca envían a ningún servidor, así que el servidor solo llega a guardar texto cifrado que no puede descifrar.

¿Qué ve realmente el servidor?

En modo tiempo real en la misma red, solo la información de establecimiento de conexión necesaria para presentar dos dispositivos entre sí — nunca los bytes del archivo. Entre redes, el retransmisor TURN sí transporta esos bytes, pero solo como texto cifrado del que no tiene la clave. Para los enlaces almacenados, ve texto cifrado más datos administrativos como el tamaño y la hora de caducidad — nunca el texto en claro, los nombres de archivo ni la clave de descifrado.

¿Es el retransmisor TURN un punto débil?

En el navegador transporta por diseño todas las transferencias entre redes, y no solo aquellas en las que falló un camino directo — pero siempre maneja únicamente texto cifrado, y no tiene ninguna clave, así que no puede leer lo que retransmite. Relayium contabiliza los bytes que retransmite contra la asignación mensual de tu cuenta, pero nunca inspecciona su contenido.

¿Es Relayium de código abierto?

Sí. El diseño del protocolo y todo el código de cliente y servidor son públicos en GitHub bajo la licencia AGPL-3.0, así que la criptografía descrita aquí puede auditarse de forma independiente en lugar de creerse a ciegas.

¿Qué pasa si los dos códigos de verificación en pantalla no coinciden?

Detén la transferencia. Dos códigos distintos significan que los dos dispositivos no están viendo la misma conexión: es exactamente lo que produciría una clave sustituida o un intermediario, no un fallo inofensivo. (Que falle el handshake de comprometer-y-luego-revelar es otra cosa, y ocurre antes: aborta la propia conexión, sin llegar a mostrar ningún código.) No continúes hasta entender por qué.

¿Quieres ver cómo funciona en la práctica? Activa la verificación avanzada antes de iniciar una nueva conexión: así la comparación del código y los pasos de confirmación se aplican desde el principio.

Prueba Relayium ahora