Un navegador puede ejecutar criptografía sólida; aun así, hay que confiar en el código que se le entrega.
Un navegador puede realizar cifrado de extremo a extremo localmente, incluido el establecimiento de claves poscuántico, sin instalar una aplicación nativa de mensajería. La pregunta difícil no es si las matemáticas pueden ejecutarse en una pestaña. Es si la aplicación entregada, el manejo de claves y la vía de actualización merecen la confianza que requiere la conversación.
El acceso web puede resultar cómodo cuando no es posible instalar aplicaciones. No hace que la aplicación sea inmune a la censura, al alojamiento comprometido, a las extensiones maliciosas ni a un dispositivo comprometido.
Los componentes criptográficos del navegador
WebCrypto expone operaciones de bajo nivel para cifrado, derivación de claves, firma y gestión de claves. Las implementaciones habituales proporcionan primitivas como AES-GCM y ECDH. Estas operaciones son componentes, no un protocolo completo de mensajería autenticada.
Una aplicación web puede incorporar una implementación revisada de ML-KEM mediante JavaScript o WebAssembly cuando no esté disponible la API nativa necesaria. La compatibilidad de los navegadores cambia, por lo que los desarrolladores deben comprobar las funciones en las versiones de destino exactas en lugar de suponer que todos ofrecen los mismos algoritmos.
Un flujo híbrido conceptual sería:
- Generar claves adecuadas con aleatoriedad criptográficamente segura.
- Autenticar el material de claves del interlocutor mediante el mecanismo de identidad del protocolo.
- Obtener aportaciones clásicas y poscuánticas al secreto compartido.
- Combinarlas según el esquema de derivación de claves especificado y el contexto de la conversación.
- Usar las claves derivadas para cifrado autenticado, gestionando correctamente los nonces y el estado.
Es un esquema explicativo, no una receta de implementación. FIPS 203 normaliza ML-KEM; no certifica una aplicación concreta de navegador ni define todos los pasos de un protocolo de chat.
La entrega mediante HTTPS forma parte del modelo de confianza
Normalmente, el servidor suministra el JavaScript y WebAssembly que procesarán el texto en claro. Una aplicación modificada maliciosamente puede leer un mensaje antes del cifrado o después del descifrado, aunque su biblioteca criptográfica utilice algoritmos sólidos.
HTTPS ayuda a autenticar y proteger la entrega frente a interferencias de red. No demuestra que el operador del origen, su sistema de despliegue o sus dependencias no estén comprometidos. Una página HTTPS normal no es automáticamente un paquete de aplicación firmado de forma independiente.
Las consideraciones de seguridad de WebCrypto del W3C abordan la inyección de scripts y la necesidad de proteger la integridad de la aplicación. Content Security Policy, una gestión cuidadosa de dependencias y otros controles de seguridad web reducen los riesgos, pero ninguno convierte cualquier script del mismo origen en un observador no fiable incapaz de tocar los datos de la aplicación.
WebAssembly también comparte el perímetro de seguridad de la aplicación. Su entorno aislado limita el acceso al sistema anfitrión mediante interfaces definidas; no hace fiable a la página que lo invoca. Compilar C a Wasm no convierte el lenguaje de origen en un lenguaje con seguridad de memoria.
Las claves no existen necesariamente solo en la RAM
Un servicio de mensajería del navegador puede conservar claves o estado cifrado para que el usuario regrese a la misma identidad. También puede ofrecer vinculación de dispositivos o recuperación cifrada. Estos comportamientos deben documentarse, no darse por inexistentes.
Conviene plantearse estas preguntas:
- ¿Qué claves se conservan y en qué almacenamiento del navegador?
- ¿Qué ocurre al borrar los datos del sitio o terminar una sesión de navegación privada?
- ¿Puede el código malicioso que se ejecuta en el contexto de la aplicación seguir utilizando una clave no extraíble?
- ¿Puede una actualización recién entregada acceder al estado local antiguo?
- ¿La recuperación restaura la identidad, el historial de mensajes o ambos?
Una clave WebCrypto no extraíble restringe la exportación mediante la API. Por sí sola, no impide que el código hostil de la aplicación solicite operaciones permitidas o recopile texto en claro.
Los clientes web y nativos implican compromisos distintos
| Aspecto | Cliente de navegador | Cliente nativo |
|---|---|---|
| Distribución | Origen, alojamiento y proceso de actualización web | Tienda de aplicaciones o distribución de paquetes y proceso de firma |
| Persistencia local | Almacenamiento del navegador y comportamiento del perfil | Almacenamiento de aplicaciones del sistema operativo y ciclo de vida de la aplicación |
| Exposición | Scripts del mismo origen, extensiones y vulnerabilidades del navegador | Dependencias de la aplicación y vulnerabilidades del sistema operativo o la aplicación |
| Disponibilidad | Dominio accesible y servicios de red necesarios | La aplicación instalada sigue necesitando sus servicios de red requeridos |
Ninguna columna establece un ganador sin examinar la implementación. Una aplicación web puede seguir siendo accesible tras su retirada de una tienda de aplicaciones, pero un dominio bloqueado o la falta de una ruta de red todavía pueden impedir el acceso.
Medir el rendimiento en lugar de prometerlo
ML-KEM-768 utiliza una clave de encapsulación de 1.184 bytes y un texto cifrado de 1.088 bytes conforme a FIPS 203. Estos tamaños ayudan a explicar por qué los protocolos pueden programar actualizaciones KEM en vez de adjuntar material nuevo a cada mensaje breve. No son mediciones del ancho de banda ni de la velocidad de toda una aplicación.
Una prueba de rendimiento útil indica el navegador, dispositivo, compilación, método de calentamiento, operación medida y distribución de los tiempos. Hay que incluir el arranque de la página, la carga de módulos, el uso de memoria, los dispositivos de gama baja y la sobrecarga de red. Afirmaciones como «menos de dos milisegundos en todos los teléfonos modernos» requieren mediciones publicadas; este artículo no las aporta.
Aplicación de estos criterios a Livara
La descripción de seguridad de Livara documenta LVR1 y los límites de su recuperación. Su Proof Lab demuestra determinadas operaciones locales P-256, HKDF y AES-GCM; la página sitúa expresamente la composición completa de LVR1/LGS1 fuera de ese banco de pruebas. Por tanto, superar una demostración no demuestra la seguridad de todo el código web distribuido.
Antes de una conversación sensible en el navegador, utilice un cliente auténtico y mantenido, revise el modelo de amenazas actual, proteja el perfil del navegador y verifique al interlocutor mediante el procedimiento admitido de comprobación de claves. La comodidad y una criptografía útil pueden coexistir siempre que el perímetro de la entrega web siga formando parte de la evaluación.
