Cifrado en el cliente para compartir secretos

El cifrado en el cliente protege un secreto almacenado frente al operador y frente a cualquiera que se haga con la base de datos, y nada más: un JavaScript malicioso, una extensión del navegador o un enlace filtrado lo anulan, porque la clave viaja en el enlace. No es una solución mágica, y esa única garantía se paga en otros sitios.

Esta guía explica qué garantiza el cifrado en el navegador, dónde falla sin que se note, cómo se compara con el modelo del lado del servidor y cómo LinkPilot combina ambos desde el 29 de septiembre de 2026, cuando su generador de enlaces secretos de un solo uso pasó a cifrar en el navegador.

Reescrito el 19 de octubre de 2026. La versión original de este artículo describía el modelo del lado del servidor que LinkPilot usaba entonces; una nota añadida el 29 de septiembre de 2026 dejó constancia del cambio. Esta versión describe en todo momento el modelo actual. El razonamiento sobre qué protege y qué no protege cada modelo no ha cambiado.

¿Qué protege realmente el cifrado en el cliente?

El secreto almacenado, frente al operador y frente a cualquiera que se haga con la base de datos. En una herramienta de secretos con cifrado en el cliente (también llamado cifrado de extremo a extremo, o E2EE), el proceso es este:

1. El navegador genera una clave simétrica, normalmente una clave AES-GCM de 256 bits, mediante la Web Crypto API (crypto.subtle.generateKey).
2. El contenido se cifra en el navegador con esa clave.
3. Solo el texto cifrado se envía al servidor, que lo guarda con un identificador aleatorio.
4. La clave se añade al enlace como fragmento (#…). Según la RFC 3986, sección 3.5, los navegadores nunca envían el fragmento en las peticiones HTTP, así que la clave no viaja hasta el servidor.
5. El navegador del destinatario lee el fragmento, descarga el texto cifrado y lo descifra en local.

El servidor solo ve texto cifrado. Un operador que lea su propia base de datos, una copia de seguridad que se filtre, una orden judicial sobre los datos almacenados: ninguno de ellos da acceso al secreto, siempre que el resto de eslabones de la cadena aguante.

Anatomía de un enlace secreto E2EE

https://example.com/s/x7Kd93hF2a#4fT9wLm2...Qz1
└──────── sent to the server ───┘└ browser only ┘

Todo lo que va antes del # viaja en la petición y puede aparecer en los registros del servidor y de los proxies. El fragmento solo lo procesa el navegador del destinatario. Ese único carácter hace todo el trabajo de seguridad, lo cual es elegante, y también es el origen de la mayoría de los fallos que se describen a continuación.

¿De qué no protege el cifrado en el cliente?

De un JavaScript malicioso o comprometido, de las extensiones del navegador y de un enlace filtrado, porque la clave está en el enlace.

• No protege de un JavaScript malicioso. El código de cifrado se ejecuta en el navegador, y el navegador recibió ese código del servidor. Si el servidor entrega código alterado, porque el operador actúa de mala fe, se ve obligado o ha sufrido un ataque, el secreto se puede leer antes del cifrado o después del descifrado. Es el límite fundamental del E2EE en el navegador.
• No protege de las extensiones del navegador. Una extensión con acceso a la página ve el texto sin cifrar después del descifrado y puede leer el fragmento directamente.
• No hace inofensivo un enlace filtrado. La clave forma parte del enlace. Si el destinatario pega el enlace completo en un chat, reenvía el correo o tiene activada la sincronización del historial del navegador, la clave viaja con él. Un enlace E2EE cuya URL se ha filtrado es un secreto completamente legible. La única defensa es una frase de contraseña enviada por otro canal, y por eso LinkPilot mezcla la frase de contraseña en la clave en lugar de comprobarla por separado.
• No audita, analiza ni previsualiza el contenido. Como el servidor no puede leer el contenido, no puede filtrarlo, buscar malware en él ni aplicarle prevención de pérdida de datos. Los controles tienen que actuar sobre el texto cifrado y sobre los eventos de acceso.

El problema de la entrega del código, en detalle

La idea que merece pensarse con calma: el E2EE en el navegador obliga a confiar en que el servidor, del que en teoría no te fías, entregue JavaScript honesto cada vez que se carga la página. Una aplicación nativa se instala una vez, firmada y con su versión; una página web se vuelve a descargar en cada visita. La integridad de subrecursos y el código fuente publicado reducen esa brecha, pero no la cierran.

Así que la lectura honesta de «no podemos leer tus secretos» es «no podemos leer tus secretos de forma pasiva». Pasar de una capacidad pasiva a un ataque activo que distribuya código modificado es un salto real (los ataques activos son más arriesgados, dirigidos y potencialmente detectables), pero no equivale a «imposible». Esto vale para lo que afirma LinkPilot tanto como para lo que afirme cualquier otro.

La alternativa del lado del servidor

El otro diseño habitual, el que LinkPilot usó hasta septiembre de 2026, cifra en reposo en el servidor y protege la visualización con una frase de contraseña con hash:

• TLS en tránsito; el contenido se guarda en una tabla dedicada de una base de datos con cifrado en reposo a nivel de disco.
• Las frases de contraseña se pasan por un hash en el navegador antes de enviarse y se comparan por hash; la frase de contraseña original nunca llega a la base de datos.
• Destrucción efectiva: en la primera visualización, al expirar o al revocarse, el contenido almacenado se sobrescribe y los intentos posteriores reciben un HTTP 410.
• Los intentos de frase de contraseña tienen un límite de frecuencia y quedan registrados.

En este modelo el servidor puede leer un secreto activo. Eso es lo que hace posibles la previsualización en el servidor, el análisis y las funciones que dependen del contenido, y es justo la propiedad que elimina el E2EE. Herramientas de código abierto como OneTimeSecret siguen usándolo; ¿es seguro OneTimeSecret? analiza las consecuencias.

Lo que hace LinkPilot ahora

Desde el 29 de septiembre de 2026, LinkPilot usa cifrado en el cliente y mantiene los controles del lado del servidor que no necesitan el contenido. Según la página de arquitectura de seguridad:

• Cifrado en el navegador. El contenido se cifra con AES-GCM-256 usando una clave de 256 bits generada en el navegador de quien lo envía. El servidor guarda el texto cifrado y nada más; la clave viaja en el fragmento del enlace.
• La frase de contraseña forma parte de la clave (Pro). Una frase de contraseña se refuerza con PBKDF2-SHA256 (210.000 iteraciones) y se combina con la clave del enlace mediante HKDF-SHA256, de modo que ni el enlace solo ni la frase de contraseña sola descifran el secreto. Los intentos se limitan a 5 por IP por minuto y por secreto, con un limitador en memoria y una ventana deslizante en la base de datos.
• Destrucción tras la lectura sobre el texto cifrado. La visualización se registra en un solo paso indivisible mediante una función de la base de datos, así que dos intentos simultáneos no pueden filtrar el secreto dos veces; el texto cifrado almacenado se sobrescribe con [REDACTED] y los intentos posteriores devuelven HTTP 410.
• Revocación. Un secreto se puede revocar desde el panel en cualquier momento; los secretos revocados no se muestran y devuelven 410.
• Visualización a salvo de vistas previas. Los generadores de vistas previas de enlaces y los escáneres de correo hacen peticiones GET, que solo devuelven metadatos (el estado y si se necesita frase de contraseña). Una visualización solo se registra cuando alguien la pide expresamente desde un navegador.
• Historial de auditoría (Pro). Creado, visto, frase de contraseña incorrecta, destruido, expirado y revocado, cada uno con fecha y hora, el país y la ciudad que indica la red perimetral, la cadena del navegador y un hash de la dirección con sal diaria. El historial registra los accesos, nunca el contenido.
• Archivos. Los archivos adjuntos también se cifran en el navegador, con una clave derivada de la clave del enlace. El nombre, el tamaño y el tipo del archivo siguen siendo visibles para LinkPilot como metadatos.

Tres límites, dichos con claridad. Los secretos creados antes del 29 de septiembre de 2026 se guardaron sin cifrar hasta que expiraron; nunca se reescribieron. Los metadatos de los archivos son visibles aunque su contenido no lo sea. Y todo lo que dice la sección sobre lo que no protege sigue siendo válido: ni este modelo ni ningún otro basado en el navegador resuelve el JavaScript malicioso, las extensiones del navegador o un enlace filtrado.

Resumen de ventajas e inconvenientes

Ningún modelo es «más seguro» en abstracto. Defienden de amenazas distintas a precios distintos, y combinarlos reduce lo que se pierde, no lo elimina.

Qué modelo encaja con cada amenaza: tres escenarios

1. Enviar a un colaborador externo la contraseña de una base de datos. La amenaza es que el secreto se quede en el correo o en el chat, o un reenvío por descuido. Cualquier modelo lo resuelve con una expiración corta y la destrucción tras la lectura; lo que decide es la facilidad de uso y el registro. Lo práctico es el cifrado en el navegador con una frase de contraseña enviada por otro canal y un historial que muestre cuándo se abrió el enlace.

2. Un periodista que recibe material de una fuente. El modelo de amenazas incluye que se obligue al operador de la plataforma a revelar datos. Aquí el operador forma parte de la amenaza, así que el E2EE es lo mínimo, y lo adecuado son herramientas creadas para ello, como SecureDrop, donde todo el sistema está diseñado en torno a esa amenaza. Una herramienta web a la que se pueda obligar a servir JavaScript alterado no basta por sí sola.

3. Un equipo de ingeniería que entrega credenciales de forma rutinaria. La amenaza es la dispersión: enlaces olvidados y ningún registro de quién vio qué. Lo que importa es el historial, la revocación, los roles del espacio de trabajo y una política de expiración. Antes eso exigía un servidor capaz de leer el contenido; ya no, porque esas funciones actúan sobre el texto cifrado y los eventos de acceso. Compartir contraseñas de forma segura en equipo trata la parte de políticas de este escenario.

Cómo elegir

Elige cifrado en el cliente cuando:

• No te fías del operador, ni siquiera de ti mismo si lo ejecutas en una infraestructura en la nube que no puedes verificar del todo.
• Las normas o los contratos exigen que el proveedor no pueda, técnicamente, leer el contenido.
• Vas a enviar la frase de contraseña por un segundo canal y a mantener una expiración corta, porque si no, un enlace filtrado equivale al secreto entero.

Elige cifrado en el servidor cuando:

• Necesitas que el servidor inspeccione el contenido: análisis de malware, prevención de pérdida de datos, filtrado de contenido.
• Alojas en tu propio servidor una herramienta de un solo propósito y el operador eres tú.

Busca ambos cuando:

• Quieres dejar al operador fuera de la cadena de confianza y aun así necesitas un historial, revocación, roles de equipo y una visualización que una vista previa del enlace no pueda activar. Pregunta al proveedor qué controles funcionan sobre el texto cifrado y cuáles necesitan, sin decirlo, el texto sin cifrar.

¿Es una herramienta de cifrado en línea la opción adecuada?

Quien busca una herramienta de cifrado en línea suele querer una de dos cosas: convertir un texto en texto cifrado que pueda pegar en cualquier sitio, o hacer llegar un mensaje confidencial a una persona de forma segura. Lo primero es una herramienta. Lo segundo es un proceso, y la herramienta sola no lo completa.

Una página donde pegas texto para cifrarlo hace el cifrado en tu navegador si está bien construida, algo que puedes comprobar con los pasos de la sección sobre cómo verificar lo que afirma una herramienta, más abajo. Lo que te deja a ti es todo lo que rodea al texto cifrado: elegir una frase de contraseña robusta, enviarla por otro canal, borrar el texto cifrado de donde lo pegaste y averiguar si el destinatario logró descifrarlo. Codificar no es cifrar, así que una herramienta de Base64 no protege nada, y una frase de contraseña débil es la forma habitual en que falla en la práctica el cifrado en el navegador.

Un enlace secreto de un solo uso hace el mismo cifrado en el navegador y se ocupa del resto del proceso: la clave viaja en el fragmento del enlace, la copia almacenada se destruye al abrirse por primera vez, el enlace expira si nadie lo abre y quien lo envía puede ver que se mostró. Para un mensaje a una persona, es lo que mejor encaja. Para texto cifrado que necesitas guardar tú, o pegar en un sistema que controlas, una herramienta local como age o GPG es mejor que cualquier página web, porque la clave no pasa nunca por un navegador.

Cuándo no usar ninguno de los dos

Hay secretos que no deberían pasar por ningún enlace. Las credenciales root de larga duración, las claves de firma de producción y las exportaciones masivas de datos van en un gestor de secretos o un KMS con control de acceso, no en una URL. Y si el destinatario necesita el valor una y otra vez, una entrada en la bóveda de un gestor de contraseñas es mejor que reenviar enlaces; el envío de un solo uso es para entregas puntuales, no para almacenar. Enlaces secretos frente a gestores de contraseñas marca esa línea.

Cómo verificar lo que afirma una herramienta

No elijas una herramienta por cuál promete más. Elige según aquello de lo que te defiendes y comprueba que lo que dice la etiqueta coincide con la arquitectura que hay debajo:

• ¿Está la clave en el fragmento? Mira la estructura del enlace; la clave debería ir después del #.
• ¿Una simple descarga del enlace devuelve el secreto? No debería.
• ¿Qué hace la frase de contraseña: da paso a la visualización o forma parte de la clave?
• ¿Qué se registra, y lo dice el operador por escrito?

Las respuestas de LinkPilot están en la página de arquitectura de seguridad, límites incluidos. A esa página se le aplica la misma prueba que a la de cualquier otro.

Lecturas relacionadas

• Cómo funcionan los enlaces secretos de un solo uso
• ¿Es seguro OneTimeSecret?
• LinkPilot frente a PrivateBin
• Enlaces secretos frente a gestores de contraseñas
• Por qué las URL filtran información confidencial
• Los escáneres de enlaces y los secretos de un solo uso

Referencias

• W3C, Web Cryptography API.
• NIST, SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
• IETF, RFC 3986, section 3.5 Fragment.
• Freedom of the Press Foundation, SecureDrop.