Qué entendemos por cifrado de extremo a extremo
Cada archivo que compartes a través de Terashare se cifra en tu dispositivo antes de salir del navegador. El servidor, nuestra capa de almacenamiento en la nube y el enjambre de igual a igual solo ven bytes ilegibles. La clave de descifrado nunca llega a nuestros servidores — viaja en el fragmento de la URL del enlace de descarga, que los navegadores nunca envían por la red.
Esto no es una promesa de marketing añadida sobre una subida normal. Es el diseño. No hay ninguna ruta en el código que permita al servidor ver un archivo en claro o una clave en claro. Si quisiéramos leer tus archivos, tendríamos que publicar código nuevo — y tú tendrías que descargarlo — y una auditoría independiente podría detectarlo. Ese es un modelo de amenaza distinto a "el servidor promete no mirar".
Con qué ciframos
| Primitiva | Propósito | Por qué esta |
|---|---|---|
AES-256-GCM |
Contenido de los archivos + cada clave cifrada | Cifrado simétrico autenticado: manipular cualquier byte hace que el descifrado falle de forma evidente. El mismo cifrado que usan HTTPS, los bancos y el cifrado de disco. |
Argon2id(opslimit=2, memlimit=64 MiB — libsodium INTERACTIVE) |
Convertir tu contraseña de inicio de sesión en una clave de cifrado de claves | Hash de contraseñas con uso intensivo de memoria — el mismo perfil que usa la bóveda web de Bitwarden. Aproximadamente 1000× más caro por intento en ataques offline con GPU/ASIC que una configuración comparable de PBKDF2. El algoritmo y sus parámetros se registran junto a tu bóveda para poder ajustar el coste (o cambiar la KDF por completo) sin romper las bóvedas existentes. |
crypto.getRandomValues |
Cada clave, cada nonce, cada salt | El CSPRNG del navegador, auditado y alineado con FIPS. Nunca generamos claves en el servidor. |
TSE2
container
|
Formato de transmisión a nivel de archivo | Un formato binario pequeño y versionado que alinea cada pieza cifrada con el límite de pieza de WebTorrent. La pieza 0 contiene una ranura de cabecera cifrada (nombre del archivo, tamaño, nonce base); todas las demás piezas se pueden descifrar de forma independiente en cuanto llegan por el enjambre — así el destinatario puede empezar a escribir el contenido en disco mientras el resto del archivo se sigue descargando. El índice de la pieza se incorpora al AAD de GCM, de modo que reordenar o empalmar piezas hace fallar la autenticación. |
Por qué esto sigue seguro en un mundo poscuántico
La mayoría de las herramientas de compartición de archivos "cifradas de extremo a extremo" dependen de RSA o curvas elípticas para intercambiar una clave entre el remitente y el destinatario. El día que llegue un gran ordenador cuántico, el algoritmo de Shor rompe ambos — de forma retroactiva. El texto cifrado registrado hoy se descifra entonces.
Terashare no realiza ningún intercambio asimétrico de claves. La clave viaja en el propio fragmento de la URL; el remitente y el destinatario la comparten por el canal en el que ya confían (correo, chat, SMS). El único ataque cuántico contra AES-256 es el algoritmo de Grover, que solo reduce a la mitad el tamaño efectivo de la clave — 256 bits se convierten en ~128 bits de seguridad poscuántica, lo que sigue estando fuera del alcance de cualquier atacante plausible en un futuro previsible.
Así que los archivos que compartes hoy a través de Terashare seguirán siendo confidenciales incluso dentro de décadas, independientemente de lo que acaben haciendo los ordenadores cuánticos.
Tu bóveda de claves personal
Una pregunta a la que toda herramienta de compartición de archivos con cifrado de extremo a extremo acaba enfrentándose: "Si solo el destinatario y yo tenemos la clave, ¿qué pasa cuando quiero volver a compartir un archivo más tarde y he perdido el enlace?" La respuesta ingenua es "no puedes". La nuestra es una bóveda de claves por usuario.
La bóveda usa una jerarquía de cifrado de sobres de tres niveles:
your login password
│ Argon2id(opslimit=2, 64 MiB, per-user salt)
▼
KEK ──── wraps ────▶ MK (random master secret)
│
│ wraps every per-file DEK
▼
DEK_1, DEK_2, DEK_3, ...
▲
│ also wraps MK ◀──── recovery key (one-time, shown once at signup)
- Tu contraseña se transforma en una clave de cifrado de claves (KEK) — íntegramente en tu navegador, nunca se envía a ningún sitio.
- Un secreto maestro aleatorio (MK) se cifra con la KEK y, de forma independiente, con una clave de recuperación de un solo uso. El servidor almacena ambos textos cifrados. No tiene forma de descifrar ninguno sin tu contraseña o la clave de recuperación.
- La clave de cada archivo (DEK) se cifra con MK y se guarda junto al envío. La copia del destinatario sigue viajando en el fragmento de la URL — pero la tuya vive en tu bóveda, así que puedes reconstruir el enlace cada vez que inicias sesión.
Why three tiers?
- El cambio de contraseña es O(1). Si cambias tu contraseña de inicio de sesión, solo volvemos a cifrar MK con una KEK nueva. Las claves de cada archivo y el texto cifrado de los archivos no se tocan, por muchos archivos que hayas compartido.
- La clave de recuperación es un sobre aparte, no el mismo secreto que MK. Nunca la vemos — se genera en tu navegador, se te muestra una sola vez al registrarte y se descarta. Puedes copiarla, descargarla como archivo de texto, guardarla en un gestor de contraseñas o imprimirla en papel. Si pierdes tu contraseña de inicio de sesión, la clave de recuperación reconstruye MK; sin ella, la bóveda es realmente irrecuperable (así que no pierdas ambas).
- ¿Lo pierdes todo? Los archivos siguen siendo recuperables. Cualquiera que haya guardado un enlace de descarga — incluido tú — puede seguir descifrando el archivo con la clave de la URL. Acceso a la bóveda ≠ acceso al archivo.
Dónde has visto este patrón antes
Esta es la misma jerarquía de cifrado de sobres que usan los principales gestores de contraseñas y sistemas de copia de seguridad con cifrado de extremo a extremo. La referencia escrita más cercana al modelo que usamos es el documento técnico de seguridad de Bitwarden , que recorre el proceso contraseña → clave estirada → cifra una clave de usuario de larga duración → cifra las claves de cada elemento. 1Password, Proton, las copias E2E de WhatsApp y la Protección de Datos Avanzada de iCloud usan todos la misma estructura.
Si confías en esos productos para proteger tus contraseñas o tus copias de iCloud, puedes confiar en la misma estructura criptográfica para proteger tus archivos compartidos.
Qué filtraría realmente una brecha en Terashare
Una buena prueba para cualquier afirmación de privacidad: preguntarse qué vería un atacante que comprometiera por completo a la empresa.
| Un atacante que robe nuestra base de datos ve… | …¿y qué puede hacer con ello? |
|---|---|
| Nombre de archivo, tamaño, URL del enlace, enlace magnet, propietario | Solo metadatos. Útiles para enrutar el envío, inútiles para leerlo. |
| DEK cifrada (por envío) + MK cifrada (por usuario) | Ambas son texto cifrado. Sin tu contraseña o tu clave de recuperación, ninguna de las dos es descifrable. |
| Texto cifrado del archivo en la nube / enjambre de WebTorrent | Parece ruido aleatorio uniforme. Sin la DEK no hay forma de leerlo más rápido que por fuerza bruta. |
| Tu contraseña, clave de recuperación, MK, DEK | Ninguno de estos llega nunca al servidor, así que no están en la brecha. |
Cómo verificar todo esto tú mismo
-
Lee el código que se ejecuta en tu navegador. La criptografía vive en dos módulos de JavaScript cortos e independientes — formato de archivo y bóveda — construidos sobre la API WebCrypto del navegador más la bien auditada
libsodium.js(compilación sumo, incluida tal cual) para Argon2id. Se sirven a cada visitante — abre DevTools → Sources para leerlos:js/services/e2ee.js— formato de archivo, cifrado, descifrado, manejo de piezasjs/services/e2ee-vault.js— bóveda: Argon2id, cifrar, descifrar, rotación, recuperación
-
Observa la pestaña de red. Abre DevTools, comparte un archivo cifrado y comprueba que los bytes que salen por la red no coinciden con el contenido de tu archivo — y que el fragmento de la URL (la parte después de
#) nunca se envía en una petición. - Mira las pruebas. Los viajes de ida y vuelta de la criptografía del navegador y las rutas de desbloqueo de la bóveda están cubiertos por pruebas de Selenium que ejecutan WebCrypto real en un Chrome real.