Cifrado
Cómo cifra Collogue un mensaje privado
Una explicación concisa del flujo de cifrado verificado en el navegador que utiliza Collogue.
Publicado: 17 de febrero de 2026
Límites de la implementación actual
Los enlaces actuales de Collogue llevan la carga cifrada en la URL. El navegador utiliza la Web Crypto API: PBKDF2-SHA-256 con 310.000 iteraciones deriva una clave AES-GCM de 256 bits a partir de la contraseña introducida por separado, con una sal aleatoria de 16 bytes y un IV de 12 bytes. El cliente actual no realiza ninguna solicitud a una API de aplicación para crear, recuperar o almacenar mensajes.
La contraseña no está codificada en el enlace. La implementación no ofrece visualización de un solo uso, eliminación en el servidor ni un temporizador de caducidad. Trate el enlace completo como sensible y comparta la contraseña por otro canal.
Contexto adicional
La idea es sencilla. Los problemas interesantes comienzan al implementarla correctamente.
Un mensaje empieza como texto legible dentro del navegador del remitente.
- el usuario;
- el navegador;
- los scripts de la página;
- las extensiones del navegador con acceso suficiente;
- el malware del dispositivo;
- los sistemas de accesibilidad y entrada.
Esto no es un defecto exclusivo de Collogue. Un secreto debe existir en algún lugar en forma legible antes de poder cifrarse.
Una clave criptográfica debe proceder de una fuente criptográficamente segura o de un proceso de derivación documentado. La aleatoriedad que parece humana no basta. Una marca de tiempo con puntuación decorativa sigue siendo una marca de tiempo.
Si interviene una frase de contraseña, la implementación debe usar una función de derivación de claves y parámetros adecuados. Si se genera una clave aleatoria, deben documentarse su longitud y el origen de generación.
- Confidencialidad — el texto cifrado no revela el texto plano sin la clave.
- Integridad — las modificaciones no autorizadas se detectan durante el descifrado.
La página pública debe nombrar la construcción exacta solo después de verificar el código. «AES» por sí solo no es una descripción completa. Importan los modos, los nonces, las etiquetas de autenticación, los tamaños de las claves, la codificación y el manejo de errores.
Las API criptográficas son famosas por ofrecer herramientas afiladas con mangos fabricados profesionalmente. Usarlas correctamente forma parte del diseño.
La forma segura esperada, si el código real la admite, es una solicitud que contenga texto cifrado y parámetros operativos, no el texto legible del mensaje.
Inspeccione el panel de red del navegador. No deduzca esta propiedad de los textos de la interfaz.
Estos valores no son automáticamente secretos. Algunos son necesarios para descifrar y pueden acompañar al texto cifrado de forma segura. La clave es la distinción fundamental.
Un enlace seguro no es necesariamente metadatos inocuos. Si poseer el enlace completo permite descifrar, el enlace es una capacidad de portador: quien lo tenga puede abrir el mensaje.
Por eso el enlace debe tratarse con aproximadamente el mismo cuidado que el secreto durante su breve vida útil.
Este detalle importa porque los sistemas automatizados pueden solicitar enlaces. Una petición GET simple es más fácil de activar para un bot de vista previa que una acción humana explícita, aunque ningún mecanismo demuestre perfectamente que intervino una persona.
El navegador del destinatario obtiene el texto cifrado y el material de clave necesario y después realiza un descifrado autenticado.
Si la autenticación falla, la aplicación debe informar de que el mensaje no pudo verificarse o descifrarse. No debe mostrar texto corrupto como si nada hubiera ocurrido.
El descifrado correcto crea texto plano en el navegador del destinatario. A partir de ese momento, la criptografía no puede impedir que copias, capturas de pantalla, fotografías o un dispositivo infectado capturen el mensaje.
El cifrado protege un trayecto. No puede controlar lo que el destinatario haga después.
Una buena página de privacidad nombra el límite en vez de sustituirlo por «desaparecido para siempre».
La conclusión correcta no es el pesimismo, sino la precisión.
Collogue debe hacer una promesa limitada, respaldarla con un comportamiento observable y explicar las suposiciones. Eso es más útil que colocar un gran icono de candado junto a un párrafo pequeño.
No. La generación segura de claves, el cifrado autenticado, los nonces únicos cuando son necesarios, la codificación correcta, las comprobaciones de integridad y el manejo seguro de errores forman parte del protocolo.
Porque el descifrado debe producir texto legible en el dispositivo del destinatario. La criptografía puede controlar el acceso antes de ese momento, no el comportamiento posterior del destinatario.
Cree un enlace privado de Collogue cuando necesite enviar una contraseña, un token, un código de recuperación u otro valor sensible breve.