Google Chrome se prepara para uno de los cambios más importantes en la seguridad HTTPS de los últimos años. En febrero de 2026, Google anunció sus planes para introducir un sistema de autenticación de sitios web resistente a los ataques cuánticos mediante Merkle Tree Certificates (MTC), un nuevo enfoque diseñado para proteger las conexiones web frente a las futuras amenazas de la computación cuántica. A diferencia de los certificados HTTPS convencionales, que dependen de cadenas de firmas digitales, los MTC combinan la emisión de certificados con registros públicos de verificación y pruebas matemáticas compactas. El objetivo es incorporar una protección criptográfica más sólida sin ralentizar de forma perceptible la navegación. Google ya ha comenzado a probar esta tecnología junto con Cloudflare, mientras que especialistas del sector trabajan en el desarrollo de estándares comunes para facilitar su adopción. Comprender este cambio es importante porque afecta a la forma en que los navegadores establecen relaciones de confianza, los sitios web verifican su identidad y la seguridad de Internet puede evolucionar durante los próximos años.
HTTPS protege la información intercambiada entre un navegador y un sitio web. Cuando una persona accede a un servicio de banca electrónica, realiza compras por Internet o inicia sesión en una cuenta, el navegador establece una conexión cifrada mediante Transport Layer Security (TLS). Un certificado HTTPS permite confirmar que el servidor pertenece al sitio web solicitado y no a un atacante que intenta suplantar su identidad. Estos certificados son emitidos por autoridades de certificación de confianza, conocidas como Certificate Authorities (CA), que verifican el control sobre los nombres de dominio antes de emitir las credenciales correspondientes. Chrome comprueba esta información al establecer una conexión segura, lo que ayuda a impedir que servidores no autorizados se hagan pasar por sitios web legítimos.
El problema es que gran parte de la infraestructura actual de certificados depende de sistemas de criptografía de clave pública que futuros ordenadores cuánticos suficientemente potentes podrían llegar a comprometer. RSA y la criptografía de curva elíptica resultan especialmente relevantes porque un ordenador cuántico con capacidad criptográfica podría utilizar el algoritmo de Shor para atacar los problemas matemáticos en los que se basa su seguridad. Actualmente, no se conoce ningún ordenador cuántico capaz de romper claves criptográficas utilizadas en Internet mediante ataques prácticos a gran escala. Sin embargo, modificar los sistemas de seguridad empleados por miles de millones de dispositivos requiere años. Esperar hasta que se produzca un ataque cuántico exitoso dejaría muy poco margen para realizar una transición segura. Por este motivo, Google ha convertido la criptografía poscuántica en una parte importante de su planificación de seguridad a largo plazo.
En marzo de 2026, Google publicó un objetivo más amplio para avanzar en su migración hacia la criptografía poscuántica de aquí a 2029. Su programa de certificados para Chrome forma parte de ese esfuerzo, aunque cada fase de implementación cuenta con sus propios plazos y requisitos técnicos. El desafío va mucho más allá de sustituir un algoritmo por otro. Los navegadores deben seguir reconociendo sitios web legítimos, las entidades emisoras de certificados tienen que adaptar sus infraestructuras y los servicios existentes deben continuar siendo accesibles durante toda la transición. Además, la solución propuesta debe funcionar de manera eficiente en redes móviles y dispositivos con menor capacidad de procesamiento, donde los mensajes de seguridad más grandes pueden aumentar los tiempos de conexión y el consumo de datos.
Los certificados HTTPS convencionales utilizan el formato X.509, que lleva décadas respaldando la autenticación de sitios web. Normalmente, un sitio presenta su certificado junto con información que lo vincula a una autoridad de certificación de confianza. El navegador verifica las firmas de esta cadena antes de aceptar la identidad del servidor. Chrome también exige que los certificados públicamente confiables cumplan los requisitos de Certificate Transparency, un mecanismo que ayuda a detectar certificados emitidos incorrectamente o sin autorización. Aunque este sistema está ampliamente consolidado, incorpora firmas adicionales e información complementaria al proceso de autenticación.
Las firmas digitales poscuánticas son considerablemente más grandes que muchas de sus equivalentes criptográficas tradicionales. Por ejemplo, el algoritmo ML-DSA-44, estandarizado por el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST), utiliza firmas de 2.420 bytes, mientras que las firmas ML-DSA-65 ocupan 3.309 bytes. En comparación, una firma Ed25519 tradicional ocupa únicamente 64 bytes. Estas cifras no representan el tamaño completo de un certificado HTTPS, pero permiten comprender por qué sustituir directamente las firmas actuales podría incrementar considerablemente la cantidad de datos de autenticación transmitidos. Cuando se necesitan varias firmas para las cadenas de certificados y los registros de transparencia, el tráfico adicional resulta especialmente relevante para los sitios web que gestionan millones de conexiones.
La respuesta propuesta por Google consiste en modificar la manera de demostrar la autenticidad de los certificados, en lugar de limitarse a aceptar archivos más grandes. En su anuncio de febrero de 2026, el equipo Chrome Secure Web Networking explicó que no tenía intención inmediata de incorporar certificados X.509 tradicionales con criptografía poscuántica al almacén público de autoridades raíz de Chrome, conocido como Chrome Root Store. En su lugar, está desarrollando Merkle Tree Certificates junto con socios del sector. Esta tecnología pretende admitir algoritmos más resistentes y, al mismo tiempo, reducir la información criptográfica que debe transmitirse repetidamente durante las conexiones. Los certificados HTTPS existentes seguirán siendo importantes durante la transición, y este nuevo enfoque no significa que el HTTPS convencional se haya vuelto repentinamente inseguro.
Los Merkle Tree Certificates utilizan un método diferente para demostrar que un certificado ha sido emitido por una autoridad de confianza. En lugar de firmar cada certificado por separado y obligar al navegador a verificar una extensa cadena de firmas individuales, una autoridad puede organizar numerosos certificados emitidos dentro de un árbol criptográficamente conectado. Después, firma una representación compacta de ese árbol, conocida como raíz o cabecera del árbol. El sitio web puede proporcionar una prueba matemática que demuestra que su certificado pertenece al conjunto firmado. De este modo, es posible autenticar certificados individuales sin transmitir repetidamente todas las firmas de gran tamaño asociadas al conjunto completo.
Un árbol de Merkle funciona calculando hashes criptográficos de los registros individuales y combinándolos a través de diferentes niveles hasta obtener un único valor raíz que representa toda la colección. Un hash es una especie de huella digital breve que se calcula a partir de determinados datos. Si se modificara el registro de un certificado, cambiarían los hashes resultantes y su prueba de inclusión dejaría de coincidir con la cabecera del árbol de confianza. El navegador no necesita descargar todo el árbol para comprobar un certificado. En su lugar, puede verificar un conjunto relativamente pequeño de hashes relacionados, lo que permite confirmar que el certificado pertenece a la colección autenticada.
La diferencia fundamental es que los árboles de Merkle no sustituyen por sí mismos a la criptografía poscuántica. Proporcionan una forma eficiente de organizar y verificar información autenticada mediante firmas digitales. La autoridad de certificación puede firmar una cabecera compartida del árbol utilizando un algoritmo resistente a los ataques cuánticos, distribuyendo así el coste de autenticación entre numerosos certificados. También pueden participar organizaciones independientes, denominadas cosignatarios o cosigners, que verifican y firman determinadas representaciones del árbol para aportar supervisión adicional. El diseño resultante combina autenticación poscuántica, pruebas compactas de inclusión y registros de emisión verificables públicamente dentro de un mismo sistema de certificados.
Certificate Transparency es un mecanismo de seguridad consolidado que permite inspeccionar públicamente la emisión de certificados de confianza. En el sistema convencional, los certificados se registran en archivos públicos para que los propietarios de sitios web, investigadores de seguridad y servicios de supervisión puedan detectar emisiones sospechosas. Los Merkle Tree Certificates incorporan este requisito directamente en su diseño. Cada certificado pasa a formar parte del árbol público de emisión de la autoridad correspondiente, de modo que la creación de un certificado válido queda vinculada a su registro en una estructura verificable. Esto reduce la separación existente entre emitir un certificado y documentar su existencia.
El sistema propuesto también depende de cosignatarios independientes y organizaciones que mantienen copias de los registros de emisión. Su participación ayuda a detectar información incoherente o intentos de presentar diferentes versiones de un registro de certificados a distintos observadores. Esto resulta importante porque una autoridad de certificación no debe considerarse fiable únicamente por su capacidad para generar una firma digital válida. La verificación pública y la supervisión independiente aportan garantías adicionales frente a errores, infraestructuras comprometidas y emisiones indebidas de certificados. Estos mecanismos no eliminan todas las posibilidades de abuso, pero refuerzan la responsabilidad de las entidades participantes y facilitan la investigación de actividades sospechosas.
Desde el punto de vista del rendimiento de los sitios web, la principal ventaja consiste en reducir los datos de autenticación que se transmiten repetidamente. Google describe dos modalidades de implementación de MTC: certificados independientes y certificados relativos a puntos de referencia, denominados landmark-relative certificates. Los MTC independientes conservan las firmas poscuánticas correspondientes durante la autenticación y ofrecen una opción de transición más sencilla. Los certificados relativos a puntos de referencia pueden evitar la transmisión de esas firmas cuando el navegador ya dispone de información fiable sobre el árbol firmado. En ese caso, el sitio web proporciona una prueba compacta de inclusión. Las mejoras reales de velocidad dependerán de la compatibilidad del navegador, las condiciones de la red, la configuración de los certificados y las decisiones de implementación. Por tanto, los MTC no deben interpretarse como una garantía de que todos los sitios web cargarán más rápido.

Google comenzó a probar los Merkle Tree Certificates junto con Cloudflare durante 2026, incluyendo experimentos con tráfico real de Internet. Los primeros trabajos de viabilidad evalúan si el método de autenticación propuesto puede funcionar de manera fiable sin debilitar las protecciones existentes. Durante estas pruebas, las conexiones que utilizan MTC también están respaldadas por certificados X.509 convencionales y de confianza. Esto proporciona un mecanismo de respaldo mientras los ingenieros analizan la compatibilidad, el rendimiento y el comportamiento de seguridad. Es una distinción importante: los experimentos exitosos demuestran avances técnicos, pero no significan que todos los usuarios de Chrome ya dispongan de una autenticación de sitios web completamente resistente a los ataques cuánticos.
El plan de implementación publicado por Google señala el primer trimestre de 2027 como el periodo previsto para incorporar operadores cualificados de registros Certificate Transparency al programa público inicial de MTC. Otra etapa, prevista para el tercer trimestre de 2027, contempla la ampliación del Chrome Quantum-resistant Root Store y la incorporación de nuevas entidades emisoras de certificados. Estas fechas representan las intenciones anunciadas por Google, no compromisos de lanzamiento incondicionales. En octubre de 2026, Google también publicó la versión 0.4.0 del borrador de su política Quantum-resistant Root Program, que establece requisitos para las autoridades de certificación, los servidores espejo independientes, la fiabilidad operativa y la supervisión pública. Por su parte, los estándares técnicos continúan desarrollándose en el Internet Engineering Task Force (IETF).
La hoja de ruta general de Chrome divide la autenticación poscuántica en cuatro etapas. En primer lugar, el navegador incorpora nuevas opciones criptográficas mientras mantiene los métodos existentes. Las fases posteriores introducen una protección más sólida frente a ataques de degradación de seguridad, establecen progresivamente la necesidad de utilizar autoridades de certificación resistentes a la computación cuántica y avanzan finalmente hacia claves de servidor también resistentes a estos ataques. Esta distinción es importante porque la simple incorporación de compatibilidad con MTC no convierte automáticamente todas las conexiones HTTPS en conexiones seguras frente a futuros ordenadores cuánticos. Mientras sigan disponibles opciones de autenticación más débiles, un atacante con capacidades suficientemente avanzadas podría intentar aprovechar esas alternativas. Por tanto, la transición debe abordar tanto la solidez criptográfica como las decisiones de confianza adoptadas por el navegador.
Para los usuarios habituales de Chrome, la transición debería requerir muy poca intervención directa. La validación de certificados normalmente se realiza automáticamente durante las conexiones HTTPS, y Google pretende conservar esta experiencia familiar. Los usuarios deben seguir manteniendo Chrome actualizado, prestar atención a las advertencias de seguridad del navegador y evitar los sitios web que presentan errores de certificados. Sin embargo, tampoco deben asumir que un candado o una conexión HTTPS demuestran que un sitio web es honesto. HTTPS protege la conexión y autentica la identidad del servidor conforme a las reglas de confianza del navegador, pero no garantiza que un sitio esté libre de estafas, descargas maliciosas o información engañosa.
Los propietarios de sitios web deberían seguir las novedades anunciadas por sus proveedores de alojamiento, redes de distribución de contenidos y autoridades de certificación, en lugar de intentar sustituir prematuramente sus certificados actuales. A medida que los servicios MTC estén disponibles, se espera que su adopción incluya actualizaciones de los procesos de emisión y renovación de certificados, con un mayor uso de la automatización. Las organizaciones que utilizan configuraciones TLS personalizadas, pasarelas de seguridad internas o programas antiguos podrían necesitar pruebas adicionales de compatibilidad. Las empresas que gestionan información sensible también deberían revisar dónde utilizan criptografía en sus servicios, ya que la autenticación mediante certificados representa únicamente una parte de la preparación frente a las amenazas cuánticas. El intercambio de claves poscuánticas, la firma de software, los sistemas internos y la protección de datos a largo plazo requieren una atención específica.
Los Merkle Tree Certificates representan un cambio considerable en los fundamentos de la seguridad de los navegadores, aunque su éxito dependerá de una implementación cuidadosa y de una amplia cooperación entre las empresas del sector. La participación de Google, Cloudflare, Apple y otros colaboradores en el desarrollo de la especificación del IETF demuestra que este trabajo va más allá de una función exclusiva de un navegador. A noviembre de 2026, los principales avances incluyen un estándar técnico en desarrollo activo, experimentos en condiciones reales y una ruta más clara hacia una infraestructura de certificados resistente a la computación cuántica. Si la transición se desarrolla satisfactoriamente, Chrome podrá verificar la identidad de los sitios web mediante una criptografía más sólida sin introducir una sobrecarga innecesaria de autenticación durante la navegación cotidiana. La prioridad inmediata sigue siendo mantener conexiones HTTPS fiables mientras se prepara el sistema de confianza subyacente para los riesgos futuros.
Google Chrome se prepara para uno de los cambios …
Durante décadas, perder la cobertura móvil significaba perder prácticamente …
Delta Force Mobile cuenta con dos experiencias multijugador principales …
Los navegadores modernos ya no dependen de la CPU …
RISC-V ha dejado de ser una arquitectura limitada a …