Mi última conferencia del año de Ciberseguridad e Inteligencia Artificial - 26 de Noviembre en Cádiz y Online

Procuro no hacer más de una veintena de charlas al año, y este año voy a cortar con el final de Noviembre, dejándome el mes de Diciembre de auténtico relax, donde espero no hacer ninguna charla. Es verdad que voy a grabar un programa de televisión, que llevo mucho tiempo sin ir a ninguno, pero será lo único que haga de aquí a finales de 2025.

Figura 1: Mi última conferencia del año de Ciberseguridad e Inteligencia Artificial.

26 de Noviembre en Cádiz y Online

En esta ocasión, bajaré el día 26 de Noviembre de 2025 al Parador de Cádiz, para dar mi última conferencia, que podréis ver tanto de forma presencial como de forma online. Eso sí, para sea cual sea la modalidad en que quieres participar, debes registrarte con anticipación en la siguiente URL:

Figura 2: Registro al Foro de "Puertos Inteligentes y Seguros"

En el programa podéis ver que yo daré la conferencia de las 10:00 de la mañana, para hablar de Ciberseguridad e Inteligencia Artificial, que servirá de telonera para la Mesa Redonda de "Innovación y Seguridad desde la Operativa Portuaria" donde estará mi querido Fran Ramírez participando.

Figura 3: Agenda del Foro de "Puertos Inteligentes y Seguros"

La jornada continuará después con un café para charlar con todos los asistentes y ponentes, y terminará con otra Mesa Redonda hablando del futuro de los puertos, con el título de "Inteligencia Artificial, Ciberseguridad y Competitividad Sostenible", para llegar a la clausura de la jornada.

Figura 4: Agenda del Foro de "Puertos Inteligentes y Seguros"

Para poder asistir, como os he dicho, es necesario registrarse, ya sea para asistir de forma presencial como para asistir de forma online. Para ello, tienes que entrar en esta URL y darte de alta rellenando el siguiente formulario. 

Figura 5: Registro al Foro de "Puertos Inteligentes y Seguros"

Y esto es todo por hoy, si quieres asistir a mi última charla del año 2025, puedes hacerlo desde cualquier lugar del mundo. Después, ya habrá que esperar al año que viene que se me está confeccionando una agenda interesante de charlas en muchos países. Ya os iré contando.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Brash: Un exploit DoS en Chromium que "mata" los Web Browsers por el "document.title"

En cuestión de días, lo que empezó como una prueba más en el laboratorio de un hacker colombiano terminó poniendo incómodo a medio ecosistema Chromium. Un simple experimento con el título de una pestaña acabó convirtiéndose en un exploit capaz de tirar navegadores modernos por todo el mundo. Y es que debajo de casi todo lo que vemos en la web hoy hay una pieza común: Blink, el motor de renderizado desarrollado por Google y adoptado por Chrome, Edge, Brave, Opera, Arc, Vivaldi y otros. Si Blink se tuerce, no se rompe solo un navegador: se resiente una parte entera de la infraestructura digital.

Figura 1: Brash, un exploit DoS en Chromium que "mata"

los Web Browsers por el "document.title"

Llevo muchos años siendo un miembro muy activo en la comunidad de ciberseguridad buscando la oportunidad de cazar bugs en plataformas, sistemas y servicios globales desde adolescente, y hoy esto y por aquí porque Chema Alonso me ha pedido que le hiciera este artículo. Hace años ya os hablé por este blog de la herramienta Trape para investigar identidades y personas, además que tienes muchas otras herramientas que publico en mi repositorio de GitHub. 

Figura 2: Repositorios de GitHub de José Pino

Hoy quería hablaros de Brash que afecta a Blink, y que demuestra cómo es posible colapsar navegadores modernos jugando únicamente con "document.title. Brash vive en el corazón de Chromium y permite lanzar un ataque de Denegación de Servicio (DoS) a escala masiva. El impacto no se mide en “unos pocos usuarios afectados”, sino en miles de millones de navegadores potencialmente vulnerables. Brash es una vulnerabilidad de Denegación de Servicio que provoca:

• Congelamiento total del navegador.
• Bloqueo instantáneo de pestañas.
• Consumo extremo de CPU y memoria.
• En algunos casos, reinicio forzado del proceso del navegador.

El ataque se ejecuta mediante un patrón específico de llamadas que genera un desequilibrio interno en los manejadores asíncronos de Chromium. En pocas palabras, una pequeña pieza de código es capaz de colapsar el navegador por completo.

Figura 3: Probar demo de Brash

Brash no requiere hacer uso de ingeniería avanzada, ni de tener acceso a memoria, hacer una manipulación de binarios donde usar técnicas complejas de ROP, JIT Spraying o similar para lidiar con las protecciones de memoria. Su peligrosidad radica en su simplicidad, su alcance global, y el hecho de que puede activarse desde cualquier sitio web, iframe o servicio que renderice contenido bajo Chromium, como hacen también millones de instalaciones de apps móviles en la industria.

Figura 4: Testeando Brash en un Web Browser no vulnerable

Chromium es el motor dominante de Internet. La combinación de Chrome, Edge, Brave, Opera, Arc, Samsung Internet y otros navegadores construidos sobre su framework alcanza una cifra que se aproxima a los 3.000 millones de usuarios activos, y cualquier navegador basado en Chromium es vulnerable. Incluso aplicaciones como WhatsApp Desktop, Discord, Slack, VSCode y apps basadas en Electron en general pueden verse afectadas si renderizan contenido que lleve el exploit de Brash.

Impacto técnico

Brash deja ver varias cosas incómodas sobre cómo está montado Chromium:

• Chromium hereda demasiado del modelo monolítico de callbacks, provocando efectos dominó difíciles de mitigar.

• No existe una protección efectiva contra tormentas asíncronas de eventos, lo cual permite que una secuencia específica sature el event loop.

• El DoS puede dispararse sin interacción del usuario.

• Facilidad de explotación, ya que un atacante puede integrar Brash en Banners, Scripts externos, Trackers, Widgets o Iframes invisibles. El resultado es un ataque simple, silencioso y de ejecución inmediata, que podría venir por cualquiera de los proveedores de contenido que utiliza una aplicación compleja hoy en día.

Brash explota una omisión de diseño en Blink, como es la ausencia total de límites en las actualizaciones de document.title, la función que define el título de una pestaña. Un sitio web malicioso puede realizar millones de cambios de título por segundo, saturando el hilo principal del navegador y forzando su colapso. El exploit provoca picos del 100 % de uso de CPU y bloqueos totales en Chrome, Edge, Opera, Brave, Vivaldi, Arc, Perplexity Comet o ChatGPT Atlas, el navegador de OpenAI.

Figura 5: Brash en GitHub

No es un bug visual. Es una falla estructural que permite a cualquier atacante hacer colapsar un sistema operativo con una sola línea de código. Firefox y Safari no son vulnerables porque utilizan motores distintos (Gecko y WebKit, respectivamente). En iOS todos los navegadores se ven obligados a usar WebKit por imposición de Apple, por lo que el riesgo efectivo de Brash se concentra en Windows, macOS, GNU/Linux y Android.

Metodología y reproducibilidad

Para no quedarse solo en la demo de turno, monté un pequeño laboratorio y repetí las pruebas una y otra vez en entornos controlados con máquinas limpias, usando navegadores recién instalados, sin extensiones ni perfil previo. Sobre estos entornos, probé escenarios progresivos, con pruebas con intensidad moderada, agresiva y extrema variando burstSize, interval y delay en la librería Brash.run.

Con estas pruebas pude observar métricas del porcentaje de uso de CPU, tiempo hasta congelación, respuesta de la interfaz, recuperación del proceso o cierre forzado. Y por supuesto, había que probar diferentes vectores de ataque, con ejecución directa en pestaña, incrustado en iframes, ventanas emergentes y entornos basados en Electron.

Figura 6: Libro de Bug Bounty: De profesión "Cazarrecompensas"

en 0xWord, escrito por Pablo García

Quería probar si esta vulnerabilidad y vector de explotación era repetible, así que cada escenario se ejecutó múltiples veces sobre Windows, macOS y GNU/Linux para descartar falsos positivos o condiciones de carrera. Hoy en día cualquier equipo de seguridad puede reproducir estos escenarios usando el repositorio oficial de Brash en GitHub y la demo pública de Brash en un entorno de laboratorio aislado. Toda la investigación, el exploit y los recursos de prueba están publicados en el repositorio oficial y en una demo pública:

• Repositorio oficial: https://github.com/jofpin/brash
• Demo en vivo: https://brash.run
• Demo oculta (sin interfaz): https://brash.run/hidden-live-demo.html

Desde ahí es posible, ejecutar el exploit directamente en tu navegador, probar diferentes niveles de intensidad (moderado, agresivo y extremo), ajustar en tiempo real los parámetros que saturan el event-loop del navegador a través de document.title.

Figura 7: Ejecución de Brash en Google Chrome in-progress

En el propio repositorio se incluye:

• exploit-demo/index.html: panel interactivo para observar cómo se degrada y colapsa el navegador según el burstSize y el interval.

• brash.js: librería lista para integrarse en PoCs, laboratorios o pruebas de estrés sobre navegadores basados en Chromium.

Con la configuración que puedes ver en la imagen siguiente, Brash intenta inyectar millones de actualizaciones de document.title por segundo, saturando el hilo principal (UI thread), bloqueando el event loop, congelando la pestaña y forzando el colapso del navegador en una ventana de entre 15 y 60 segundos, tal y como se documenta en el README del proyecto.

Figura 8: Ejemplo de uso mínimo con la librería oficial (extremo).

Esta vulnerabilidad abre una serie de riesgos reales que podrían afectar a usuarios, empresas y organizaciones, ya que un sitio web podría inutilizar el navegador del visitante, y un servidor vulnerable a Client-Side Attacks podría permitir a un solo adversario inutilizar las conexiones de todos sus clientes.

Figura 9: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

Un servicio de anuncios podría provocar bloqueos masivos a escala mundial, y podría usarse para takedowns forzados, derribando navegadores de objetivos específicos. En entornos empresariales, puede causar interrupciones masivas, porque además Brash es un ataque silencioso, global, de bajo costo y prácticamente imposible de mitigar, ya que aún no cuenta con un parche de seguridad.

¿Por qué Brash no es "otro DoS de navegador"?

La mayoría de vulnerabilidades de Denegación de Servicio en navegadores se limitan a APIs muy concretas o a formatos de recurso específicos, no escalan bien entre diferentes versiones, sistemas operativos o entornos embebidos y requieren condiciones concretas o una interacción notable del usuario. Brash, en cambio se apoya en un comportamiento completamente legítimo (document.title) que existe desde hace años, afecta a todo un ecosistema dominante basado en Chromium, incluyendo navegadores y aplicaciones Electron. 

Figura 10: Ejecución de Brash en Google Chrome

Además es extremadamente barato de integrar en cualquier página, banner, script de tracking o iframe invisible y puede activarse sin clics por parte del usuario, sin permisos especiales y sin tocar memoria. Ese salto —de bug raro a patrón que cualquiera puede reciclar— es lo que hace que Brash no sea sólo otro fallo curioso para coleccionar.

Brash no es un bug más. Es el recordatorio incómodo de que incluso los ecosistemas mejor montados pueden caerse por algo tan tonto como un título de pestaña. Cuesta encontrar este año un fallo de navegador con un alcance parecido.

Saludos,

Autor: José Pino (Contactar con José Pino)

Whisper Leak: Cómo espiar conversaciones cifradas que se tienen con un LLM y cómo mitigar este ataque con ofuscación

El delicado equilibrio entre seguridad y privacidad siempre está en riesgo de balancearse de un lado a otro. Algunos, sufren cuando la privacidad evita que un malo sea detectado o le dota al atacante de herramientas que puede explotar, mientras que la seguridad puede estar tentada a hacer un uso excesivo de sus capacidades de vigilancia y tornarse en un déspota que aproveche esa posición de poder para degenerar en algo más allá que proteger a las personas. Este debate, en el mundo tecnológico, lo hemos tenido siempre.

Figura 1: Whisper Leak: Cómo espiar conversaciones cifradas

que se tienen con un LLM y cómo mitigar este ataque con ofuscación

En el caso de las conversaciones vía Prompt que se tienen con un LLM, la industria está investigando cuáles son esas medidas de privacidad y vigilancia, y cuál es el equilibrio que existe entre ellas. En el caso de los Prompts y las respuestas enviadas a un modelo LLM, utilizamos criptografía donde ciframos con TLS los datos enviados y recibidos, y asumimos que si un atacante es capaz de acceder a esa información, no podrá descifrarla.

Figura 2: Hay que asumir que el atacante puede acceder al tráfico cifrado

Dejando al margen que el atacante pueda esperar a la llegada de los ordenadores cuánticos y esté utilizando una estrategia de Harvest-Today-Decrypt-Tomorrow, - ,motivo por el que habría que cifrar toda esa comunicación con algoritmos de Post-Quantum Cryptography, la pregunta que se hacen los investigadores es, ¿es posible sabe de qué están hablando un LLM y un usuario - o un Agentic AI - solo con las cadenas de datos cifrados intercambiados entre ellos?

Figura 3: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica. 

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

La respuesta a esta pregunta ya la vimos en el trabajo del año pasado de "What Was Your Prompt? A Remote Keylogging Attack on AI Assistants" del que os hablé en el artículo de "Ataque de Side-Channel a conversaciones con ChatGPT, CoPilot y otros LLMs" donde los investigadores aprovechaban los datos de cifrados de las conversaciones que se tenían con diferentes LLMs para pasarlos por un Clasificador de Machine Learning que, mirando los tamaños y las conversaciones, el número de conversaciones, y los tiempos entre ellas, era capaz de clasificar los tipos de conversaciones con una muy precision.

Figura 4: Un clasificador de Machine Learning detecta los temas por

los tamaños y tiempos de conversaciones de datos cifrados

Investigadores de Microsoft, este mismo mes, han publicado un trabajo titulado: "Whisper Leak: A side-channel attack on Large Language Models" que ahonda en esa idea, añadiendo nuevos puntos de información para hacer el clasificador de Machine Learning mucho más poderoso. En este caso han añadido las secuencias de tiempos de las conversaciones, que al final son un proxy al Thinking Time. 

Figura 5: Whisper Leak: A side-channel attack on Large Language Models

Con estos datos añadidos al clasificador, lo que sucede es que detectar que se está hablando de un topic vigilado, por ejemplo "Money Laundary" es mucho más efectivo, incluso si las conversaciones tienen entre medias intercambios ruidosos de temas no relaciones.

Figura 6: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Esto abre un nueva de vigilancia a escala. Imaginemos que una organización quiere vigilar a todos los empleados de una organización quién está hablando de un tema, o aún más locura, imaginemos que un gobierno déspota quiera controlar todas las conversaciones a nivel de un país y saber quién está hablando de un determinado tema. Incluso con sistemas de cifrado, con un clasificador de Machine Learning analizando los datos encriptados de la comunicación TLS entre los ciudadanos y los modelos LLM transferidos podría llegar a saberse quién está hablando de qué. En el trabajo utilizan, para aumentar la efectividad del clasificador lo siguientes datos:

• Token Lenght Side Channel: En el trabajo de "What Was Your Prompt? A Remote Keylogging Attack on AI Assistants" demostraron como se podía inferir la longitud del token a partir de la longitud de los datos cifrados.

• Timing Sequences: En este caso, se basan en el trabajo de "Remote Timing Attacks on Efficient Inference" que demuestra que dependiendo de los tiempos de respuesta se puede inferir los temas de los que está tratando una conversación. Al final, el tiempo de respuesta es un proxy al tiempo de componer la repuestas (Thinking Time) y puede ser utilizado para clasificar los temas con un modelo de Machine Learning.

• Timing Sequences para contar Tokens: Las secuencias de tiempo no solo se pueden utilizar para inferir los temas, sino que también se pueden utilizar para inferir el número de los tokens que se están intercambiando, que por ende - el número de tokens - son también una inferencia del tema que se está tratando, como explica el trabajo de "Time Will Tell: Timing Side Channels via Output Token Count in Large Language Models"

• Timing Side-Channel via Cache Sharing: El último de los trabajos que exploró el uso del tiempo como Side-Channel para filtrar información es el de "InputSnatch: Stealing Input in LLM Services via Timing Side-Channel Attacks" que se aprovecha de las optimizaciones de caché que muchos LLM utilizan para optimizar los resultados. Al final, se puede hacer un Cache Snooping basado en el tiempo de respuesta. Es decir, el usuario hace peticiones que llevan tiempo responder, y el modelo almacena esos tokens en la caché que luego reutilizará si alguien pide esa misma información. Midiendo los tiempos de respuesta de temas que deberían ser largos se puede saber si ese tema ha sido preguntado cuando el tiempo de respuesta sea corto.

Utilizando todos estos estudios, los investigadores han construido un clasificador de Machine Learning que consigue unos resultados de acierto altísimo para saber cuándo una conversación ha tenido que ver con un determinado tema para el que ha sido entrenado. En el experimento han utilizado tres diferentes arquitecturas para entrenar el modelo de inferencia, basadas en LightGBM, en LSTM y BERT, y los resultados de detección de un determinado tema entre conversaciones que no tienen nada que ver con ese tema son altísimos.

Figura 7: Ratio de detección de un tema concreto en conversaciones con ratio 10.000-1

noise-tema objetivo tras cinco intentos frente a diferentes modelos LLMS

Claro, llegado a este punto, estamos en la dicotomía de elegir entre Privacidad y Seguridad. Se podría utilizar esta capacidad también para atrapara a los malos, pero el balance es que tendríamos que poner en riesgo la privacidad de todas las personas para algo que, al final, dejaría de ser efectivo, porque... ¿utilizaría el malo este sistema de comunicaciones si supiera que le pueden detectar? La respuesta es no, y por el camino todos los ciudadanos quedarían expuestos. Por eso, los investigadores proponen añadir medidas de protección contra este tipo de inspección basadas en tres formas de ofuscación.

Medidas de mitigación

La primera de las opciones que proponen es hacer un Random Padding para evitar que la longitud de los tokens que se envían sea constante y repetible, esto es algo que mis compañeros Celso Martinho y Michelle Chen explicaban cómo los habían añadido a las capacidades de Cloudflare para despliegue de Servicios con nuestra AI Security Suite. Lo tenéis explicado en el artículo de "Mitigating a token-length side-channel attack in our AI products".

Figura 8: En el despliegue de Cloudflare se añade el padding en la propiedad "p" como se

explica en el artículo de "Mitigating a token-length side-channel attack in our AI products".

La segunda de las propuestas es hacer Token Batching, o lo que es lo mismo, agrupar aleatoriamente grupos de tokens, lo que reduce drásticamente la observabiliadad del número de tokens y el tamaño de las conversaciones. Esto dificulta la efectividad del clasificador de Machine Learning, y por lo tanto ayuda a la privacidad.

Figura 9: Tokens de ofuscación en respustas de microsoft-gpt-4o

La tercera es hacer Packet Injection y meter aleatoriamente tokens sintéticos en el medio de las conversaciones para ofuscar la conversación. De nuevo, el objetivo es cambiar el número de tokens para hacer más difícil la labor de la clasificación.

Figura 10: Eficacia de las medidas de mitigación propuestas

Con estas protecciones, se puede ver cómo los ratios de mitigación permiten tener sistemas que reducen la efectividad del ataque en más de un 90%, por lo que deberían ser desplegadas cuanto antes en cualquier servicio que se despliegue utilizando LLMs.

Figura 11: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cuánto del tráfico en Internet funciona con Post-Quantum Cryptography

Este mes está teniendo lugar la formación de Quantum Security de la Universidad de Deusto que termina la semana que viene, y en él participé dando una charla de Post-Quantum Internet, donde hablaba de cómo se están desplegando las soluciones de Post-Quantum Cryptography que ya tenemos estandarizadas por el NIST.

Figura 1: Cuánto del tráfico en Internet funciona con Post-Quantum Cryptography

De estos temas he hablado muchas veces, e incluso hemos publicado un libro llamado "Quatum Security: Tecnología Cuántica & Ciberseguridad. Criptográfica Cuántica y Post-Cuántica", donde hemos trabajado junto con la Universidad de Deusto, Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero, Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas, y yo mismo, que he hecho un par de capítulos de este volumen.

Figura 2: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica. 

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

El libro, está dedicado a uno de los temas que más está preocupando a las empresas - además de la IA, por supuesto - en temas de seguridad, como es la llegada de los Quantum Computers, y el uso de tecnologías de criptografía que esté preparadas para este momento, y de estos temas tienes publicados artículos que te recomiendo que leas si te interesa el tema:

• Quantum Computing Cybersecurity Preparedness Act: Comienza la era de Ciberseguridad Post-Quantum en Estados Unidos
• Hamming Quasi-Cyclic (HQC-KEM): Nuevo Key-Encapsulation Mechanism en Post-Quantum Cryptography
• FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"
• La Gran Búsqueda de Números Primos de Mersenne en Internet para superar el mayor Número Primo conocido hasta la fecha
• Cómo acelerar los algoritmos de Inteligencia Artificial con Computadores Analógicos Ópticos (AOC)
• Premio Nobel en Física 2025: El trabajo del "Efecto Tunel" que trajo la cuántica a nuestro mundo y abrió la puerta a los ordenadores cuánticos
• Un Reloj Atómico Óptico del MIT con Optimización Cuántica para medir el Tiempo del Futuro
• Quantum Cryptography: Una comunicación con cifrado cuántico
• Factorización de RSA con un Optimizador de Quantum Computing (y Classic Computing)

También puedes participar, comentar y aprender, además, en el Foro de Quantum Security al que puedes conectarte con tu cuenta de MyPublicInbox. Primero inicia sesión con tu cuenta de MyPublicInbox, y luego visita este enlace para poder entrar en el foro.

Figura 3: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Dicho todo esto, la pregunta sobre "Cuánto del trafico en Internet funciona con Post-Quantum Cryptography" es algo que podemos conocer con una buena aproximación gracias a los datos que podemos ver en Radar de Cloudflare.

Figura 4: Data Explorer de Radar.

Seleccionando peticiones HTTP y Post-Quantum

Para ello podemos ir a la sección de Data Explorer y seleccionar por el protocolo HTTP y seleccionar la opción de Post-Quantum, como podéis ver en la imagen anterior. Al hacerlo, nos arroja que el gráfico siguiente donde podemos ver que la media de esta última semana ha dado un 42% del mismo con soporte PQC.

Figura 5: 42% de las conexiones HTTP con PQC supported

En Data Explorer de Radar tienes la opción de ver cuál ha sido la petición de la API que se ha enviado y cuales han sido los datos que se han recibido, para poder hacer una integración de estos datos en otro tipo de paneles de observabilidad de Internet, que te puede resultar muy útil.

Figura 6: Petición de la API de Data Explorar para HTTP PQC

Sin embargo, si queremos tener una visión de cómo ha ido evolucionando el despliegue de PQC en Internet en los últimos 12 meses, tenemos que hacer una selección de un rango mayor de datos, y obtendremos una curva mucho más significativa de cómo está avanzando el nuevo Post-Quantum Cryptography Internet.

Figura 7: Evolución del soporte PQC en las conexiones HTTP en el último año

Como se puede ver, en media ha sido un 30%, pero venimos de poco más del 10% hace una año para acabar por encima del 42% del soporte PQC en HTTP en esta semana. Esto se debe al aumento del soporte de PQC por grandes proveedores tecnológicos. 

Figura 8: Curva de adopción de HTTP PQC

Hoy en día Mozilla Firefox, Google Chrome y Android soportan por defecto PQC en modo Hybrid, y con el lanzamiento de iOS 26 Apple ha pegado otro acelerón a HTTP PQC en la parte de cliente. 

Figura 9: Cloudflare soporta PQC en toda su red

Por otro lado Cloudflare comenzó el despliegue masivo de PQC en todas sus conexiones en el año 2023, y está ayudando a dividir el problema entre el cliente y la red de Cloudflare y entre la red de Cloudflare y el servidor.

Figura  10: OpenSSL 3.5 con Hybrid ML-KEM en TLS v1.3

En la parte de servidores, la fundación OpenSSL lanzó la versión 3.5 con soporte en modo Híbrido de ML-KEM en TLS v1.3, por lo que todos los servidores que tengan esta versión desplegada y configurada, ya están listos con soporte PQC.

Figura 11: Algoritmos de Signature PQC

Sin embargo, si vamos a la parte de firmas de los certificados digitales, vemos que el uso de algoritmos PQC no está nada extendido, y nos queda mucho por hacer. Para ello, en Data Explorer seleccionamos la opción de Certificate Transparency y Signature Algorithms.

Figura 12: Data Explorer Certificat Transparency Signature Algoritms

Como podéis ver, los resultados arrojan que todavía el despliegue mayoritario en Internet sigue siendo de criptografía tradicional, basada en RSA y ECDSA SHA, como se ve en la gráfica siguiente.

Figura 13: Algoritmos de firma en Certifiate Transparency

Todos estos datos nos arrojan un crecimiento y velocidad en el despliegue del nuevo Post-Quantum Internet que tenemos que crear, pero aún queda trabajo que hacer, y va a exigir hacer actualizaciones de muchas piezas de software en este mundo.

Figura 14: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

Dentro de poco, tener sistemas que aún usen sistemas criptográficos con RSA va a ser "Deuda Técnica", así que más vale que comiences a hacer tu plan de Quantum Safe o Quantum Readiness porque no va a ser algo que te vas a poder saltar.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El Benchmark de la ORCA que suspende en cálculo a ChatGPT-5 y Claude Sonnet, y aprueba por los pelos a Gemini, Grok y DeepSeek

Muchas veces he hablado del problema que tiene la "Creatividad" en los LLMs. Esto hace que tengamos Hallucinaciones, Errores, Sesgos y posibilidades de Envenenamiento de las respuestas. Cuando creas un servicio digital que utiliza un LLM tienes que contar con cómo tomar medidas para gestionar estos riesgos - además de los de Jailbreak, Prompt Injection y Desalineamiento -. Es el mundo AI-First que tenemos hoy en día.

Figura 1: El Benchmark de la ORCA que suspende en cálculo a ChatGPT-5

y Claude Sonnet, y aprueba por los pelos a Gemini, Grok y DeepSeek 

En el estudio de hoy, titulado "The ORCA Benchmark: Evaluating Real-World Calculation Accuracy in Large Language Models" tenemos un claro ejemplo de cómo todos los modelos de frontera que tenemos hoy en día aún comenten muchos errores en el cálculo y la resolución de problemas que exigen hacer una correcta aplicación de fórmulas para calcular un resultado exacto a un problema dado.

Figura 2: The ORCA Benchmark: Evaluating Real-World

Calculation Accuracy in Large Language Models

Lo que han hecho en este experimento es testear bien, con problemas de diferentes ámbitos científicos y técnicos las capacidades de calcular resoluciones exactas de los supuestos, divididas en diferentes áreas de trabajo, para ver si aplican con exactitud los conocimientos.

Figura 3: Clasificación de los problemas de cáclulo en el benchmark de ORCA

Con estos problemas se busca conocer algo de lo que ya vimos con el Ratio Potenkim, donde un modelo responde bien a las preguntas que tienen que ver con el concepto de conocimiento, pero fallan en su aplicación. Por ejemplo, en este imagen hay uno de los problemas que son parte del benchmark probado.

Figura 4: Prueba de un ejercicio a resolver

Como podéis ver en la imagen anterior, ChatGPT-5, Claude Sonnet4.5 y DeepSeek V3.2 fallan en la precisión del cálculo, generando errores de cálculo, lo que inyectaría errores en cualquier servicio digital que tuviera que resolver un problema similar, especialmente cuanto estamos hablando de Agentic AI en la empresa para manejar finanzas, por ejemplo.

Figura 5: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Si miramos la tabla siguiente, podemos ver como del Benchmark de ORCA, la máxima puntuación la saca Gemini 2.5 Flash con un 6.3, un "Bien" bajo, con Grok cerca y DeepSeek V3.2 aprobando con un "Suficiente" 5.2, mientras que ChatGPT-5 se queda a décimas del cinco y Claude Sonnet a medio punto del aprobado.

Figura 6: Puntuaciones en el Benchmark de ORCA

Si miramos los ejemplos, podemos ver que los problemas están pensados para resolver problemas de ciencia que exigen el conocimiento de las fórmulas, las unidades de medida, las conversiones entre ellas, y hacer cálculos exactos, que es lo que se necesita para utilizar estos modelos de IA en soluciones de robótica, gestión empresarial, medicina, etcétera, donde estos errores por "creatividad" que generan las "hallucinations" pueden tener un gran impacto.

Figura 7: Ejemplo de problema de física

Si miramos los resultados que consiguen los diferentes modelos por cada una de las áreas de estudio. En ellos vemos que DeepSeek no está para hacer medicinas y que como le dejes los componentes químicos a mano lo mismo "la lía parda". ChatGPT-5 es el peor en Health & Sport y en problemas de Estadística y Probabilidad. Sonnet el último en Física, Ingeniería, Finanzas y Matemáticas.

Figura 8: El mejor y el peor por categoría

Los resultados no son buenos para sacar una buena nota en Selectividad, y algunos problemas cuentan con errores que son bastante claros a la hora de su resolución. En esta imagen siguiente tenemos un problema de Finanzas y Economía, donde se equivoca a la hora de calcular el interés compuesto.

Figura 9: Grok se equivoca con el Interés Compuesto

Este tipo de errores en la resolución de problemas los habíamos visto también con el famoso "Ataque del Gato", donde si no le das los datos de una forma clara y limpia - es decir, haciendo Prompt Engineering a tope - el resultado es que se puede forzar el error.

Figura 10: El Cat Attack con éxito en Perplexity.

Se equivoca al hacer los cálculos de finanzas.

Si miramos por tipo de error que comenten los diferentes modelos, vemos que la precisión y el error de cálculo es el error más común que comente todos los modelos. No son buenos haciendo los números finos, está claro.

Figura 11: Porcentajes de tipos de error por tipo según los modelos

En el siguiente ejemplo, lo que tenemos es un tipo de error que tiene que ver con una mala elección de la fórmula que tiene que aplicar para resolver un problema. Es decir, el fallo que comete aquí DeepSeek no es de cálculo matemático, sino de mal razonamiento a la hora de elegir la fórmula a aplicar.

Figura 12: Error de DeepSeek aplicando la fórmula que resuelve el problema

En el siguiente problema, a pesar de que tiene todos los datos necesarios, ChatGPT-5 responde que no tiene datos suficientes para resolver el problema, así que es una deficiencia en el razonamiento relativo al problema expuesto.

Figura 13: Problema de razonamiento a la hora de resolver un problema

Y el último de los problemas que os dejo - hay más en el paper académico que os recomiendo leer - tenemos un problema de estadística y probabilidades que ChatGPT no resuelve correctamente.

Figura 14: Error al hacer un cálculo de probabilidad

Todos estos errores pueden ser utilizados por un atacante para conseguir forzar un error en los cálculos que hace un sistema de manera dirigida, es decir, que no sea un error aleatorio sino un error dirigido para conseguir un determinado precio, un determinado comportamiento, o un determinado error que genere un flujo de instrucciones concreto. Un issue de lógica que puede implicar un cambio controlado por un atacante en la lógica de un programa.

Figura 15: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)