1Password completa TLS post-cuántico en todos sus clientes sin tocar el código de aplicación

1Password ha anunciado que todos sus clientes propios (first-party) —las aplicaciones y servicios que la compañía controla directamente— ya pueden negociar TLS post-cuántico híbrido. Esto significa que todos los datos de las bóvedas transmitidos por internet a través de sus apps y servicios quedan protegidos frente a ataques de tipo "harvest now, decrypt later" (HNDL), en los que un adversario captura hoy tráfico cifrado con la esperanza de descifrarlo en el futuro con un ordenador cuántico suficientemente potente.

Este anuncio completa un proceso que la empresa inició en marzo, cuando logró que los navegadores compatibles pudieran negociar el grupo híbrido X25519MLKEM768 al conectarse a la web app de 1Password. Aquel primer hito solo cubría el tráfico de navegador, porque en TLS 1.3 la negociación de claves es un proceso de dos partes: el cliente ofrece los grupos de intercambio de claves que soporta y el servidor elige uno de esos grupos. En marzo, el lado servidor ya ofrecía soporte post-cuántico, pero solo los navegadores que ya incluían X25519MLKEM768 podían aprovecharlo. Quedaba pendiente el resto de formas de conexión: las aplicaciones nativas de 1Password, que usan una pila TLS empaquetada y controlada por la propia empresa.

El nuevo hito resuelve precisamente ese lado del cliente. El diseño híbrido combina el intercambio de claves clásico X25519 con el mecanismo post-cuántico ML-KEM-768, de modo que se mantiene la protección clásica actual mientras se añade resistencia frente a un futuro adversario cuántico. Con ambos lados —cliente y servidor— ofreciendo y seleccionando ese grupo híbrido, la negociación ocurre de forma transparente: el usuario no necesita activar ninguna opción ni cambiar su forma de usar la aplicación.

Lo llamativo del caso, tal como lo describe la propia compañía, es la sencillez técnica de la migración. En el servidor, bastó con un único cambio de política en sus Application Load Balancers de AWS, aplicado a todos los endpoints de su API, sin modificar código de la aplicación. En el cliente, su pila TLS se basa en Rustls para la gestión de conexiones y rustls-platform-verifier para certificados, que hasta ahora usaba "ring" como proveedor criptográfico. El cambio consistió en seleccionar "aws-lc-rs" como proveedor, lo que habilitó el soporte post-cuántico y convirtió a X25519MLKEM768 en el grupo de intercambio de claves preferido. En términos concretos, fue una modificación de una sola línea en el archivo Cargo.toml del proyecto.

Según 1Password, esto fue posible gracias a la "agilidad criptográfica" incorporada en su diseño: al mantener el proveedor criptográfico desacoplado de la lógica de aplicación, pudieron desplegar el nuevo esquema sin desplegar un nuevo servicio, sin migrar de balanceador de carga y sin introducir una pila TLS distinta. La pila TLS, la lógica de red y la lógica de negocio permanecieron intactas.

El cambio de proveedor a aws-lc-rs no solo aportó soporte post-cuántico, sino también implementaciones criptográficas de alto rendimiento y algoritmos con verificación formal. La compañía cita cifras reportadas por AWS: una mejora media del 113% en el rendimiento de X25519 y de entre 2,0x y 2,4x en ML-KEM-768 respecto a implementaciones anteriores, además de pruebas de corrección funcional para las rutinas centrales de X25519 y propiedades de seguridad y corrección verificadas mediante herramientas automáticas en mlkem-native.

1Password subraya que tanto la migración del cliente como la del servidor se apoyaron en trabajo ya realizado por AWS y por mantenedores de proyectos de código abierto: el Application Load Balancer expone la política de TLS post-cuántico híbrido de forma gestionada, AWS-LC aporta la implementación criptográfica, aws-lc-rs la expone a Rust, y Rustls la integra a través de su modelo de proveedores. La compañía no tuvo que escribir ni mantener su propia implementación criptográfica post-cuántica ni desplegar servicios nuevos; su trabajo se limitó a inventariar las rutas de conexión existentes, actualizar las compilaciones, probar las plataformas soportadas, desplegar de forma gradual y monitorizar la compatibilidad.

La empresa enmarca este anuncio como un hito más dentro de una hoja de ruta post-cuántica más amplia, que describe como "pragmática y basada en riesgo": consideran el tráfico de internet como el riesgo HNDL más inmediato en la actualidad, razón por la que empezaron por ahí, y afirman que su inventario criptográfico guiará las siguientes prioridades, con la promesa de publicar nuevos hitos a medida que avancen.

Más allá del caso concreto, este anuncio ilustra un patrón relevante para cualquier organización que gestione infraestructura crítica en la nube: la migración a criptografía post-cuántica no tiene por qué implicar reescribir código propio ni asumir el riesgo de implementar primitivas criptográficas nuevas desde cero. Cuando la arquitectura separa claramente el proveedor criptográfico de la lógica de aplicación, adoptar mejoras de seguridad como el intercambio de claves híbrido puede reducirse a cambios de configuración y de dependencias, apoyándose en infraestructura ya construida y verificada por terceros como AWS y la comunidad de código abierto. Es un ejemplo concreto de cómo el diseño de sistemas pensado de antemano para la "agilidad" —ya sea criptográfica o de otro tipo— puede convertir una transición que en otras organizaciones requeriría meses de reingeniería en un cambio de una sola línea.