Última actualización: 2026-07-09
«¿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.
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.
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 lo muestran en pantalla. Si los códigos coinciden, las claves no se sustituyeron y nadie está en medio. 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.
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.
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.
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.
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.
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.
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.
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.
Detén la transferencia. Una discrepancia significa que la comprobación de comprometer-y-luego-revelar falló, lo que apunta a un posible intermediario más que a un fallo inofensivo — no continúes hasta entender por qué.
¿Quieres ver cómo funciona en la práctica? Inicia una transferencia y comprueba tú mismo cómo aparece el código de verificación.
Prueba Relayium ahora