Claves de cifrado
¿Dónde está la clave de descifrado?
Por qué Collogue usa una contraseña introducida por separado en vez de poner la clave en la URL.
Publicado: 28 de febrero de 2026
Límites de la implementación actual
El cliente actual cifra el texto en el navegador y lleva el contenido cifrado en la URL. La contraseña compartida por separado no forma parte del enlace. No existe un servidor de aplicación que almacene, recupere, elimine o consuma mensajes una sola vez.
Contexto adicional
El cifrado sustituye un problema difícil por otro.
Las claves son pequeñas. Sus consecuencias no.
Una clave de cifrado simétrico permite al navegador del destinatario transformar el texto cifrado autenticado en texto en claro.
``text https://collogue.net/m/example-message#example-key-material ``
Use este ejemplo solo si coincide con la arquitectura real.
El fragmento es la parte de una URL que aparece después de #.
``text https://example.test/message/123#key-material ``
``text /message/123 ``
El navegador conserva #key-material localmente y lo pone a disposición de la página cargada.
Pero hay tres advertencias importantes.
Primero, el JavaScript cargado por la página puede leer el fragmento. El descifrado en el navegador necesita esto o un mecanismo equivalente.
Segundo, el enlace completo se convierte en una capacidad. Cualquiera que lo obtenga puede recibir tanto la referencia al texto cifrado como la clave.
Tercero, los fragmentos pueden filtrarse por el comportamiento humano, las capturas de pantalla, el texto copiado, las extensiones del navegador, el historial del portapapeles, las herramientas de sincronización o el código modificado del cliente.
Un fragmento es un límite de protocolo útil. No es un campo de fuerza.
- registros de acceso;
- registros del proxy inverso;
- historial del navegador;
- diagnósticos copiados;
- datos de referencia, según la política y la navegación;
- sistemas de monitorización.
En ese caso, el artículo público debe explicar la exposición real en vez de describir el comportamiento de los fragmentos.
Una frase de contraseña fácil de recordar y una clave uniformemente aleatoria no son intercambiables. Importan los parámetros de derivación.
A veces los usuarios creen que un enlace cifrado es seguro para publicarlo porque «solo contiene datos cifrados».
Esa conclusión es errónea cuando el enlace también proporciona la capacidad de descifrar.
- gestores públicos de incidencias;
- canales compartidos con miembros innecesarios;
- servicios de análisis de URL;
- acortadores de URL públicos;
- documentos con acceso amplio.
Poseer el enlace puede demostrar que alguien posee el enlace. No establece necesariamente la identidad.
Si un atacante obtiene la URL antes que el destinatario previsto, la criptografía puede funcionar perfectamente para el atacante.
Esta es la lección recurrente de las capacidades de tipo bearer: la autorización está representada por la posesión.
Para secretos de mayor riesgo, verifique al destinatario y considere un canal separado para el contexto o una autenticación adicional. No describa los canales separados como seguros automáticamente; solo cambian los requisitos del ataque.
- el remitente comparte el enlace equivocado;
- el destinatario lo reenvía;
- el malware del navegador lee el fragmento;
- un script malicioso de la página captura el texto en claro;
- el historial del portapapeles conserva la URL;
- un escáner de enlaces solicita la página;
- el destinatario guarda el mensaje descifrado.
Puede ser un diseño útil porque el fragmento normalmente no se envía en las solicitudes HTTP. La seguridad sigue dependiendo de la página entregada, el entorno del navegador, el tratamiento del enlace y el comportamiento del destinatario.
Sí. El JavaScript que se ejecuta en la página puede acceder al fragmento. Así es como el descifrado del lado del cliente suele obtener el material de la clave.
Si Collogue no conserva ni deriva la clave, perder el material necesario del enlace puede hacer que el mensaje sea irrecuperable. Confirme la implementación antes de publicar esa afirmación.