Un informático en el lado del mal

Tempos por Tweets: Tempos para tu Comunidad, y Tempos por apoyar perfiles en X

noreply@blogger.com (Chema Alonso) — Mon, 24 Aug 2026 06:18:53 +0000

El servicio de Tempos x Tweets lleva años funcionando en MyPublicInbox, pero recientemente ha sufrido un rediseño de funcionamiento, y quería contaros cómo funciona. Yo reparto todos los días Tempos gratis a todos los usuarios de Twitter/X que me apoyan por MyPublicInbox, y hace que los artículos que escribo lleguen a más gente, además de que permite a los que me apoyan conseguir Tempos.

Figura 1: Tempos por Tweets - Tempos para tu Comunidad,

y Tempos por apoyar perfiles en X

Además de repartir Tempos entre los que te apoyan, también puedes ganar Tempos apoyando a otros perfiles públicos que promocionan sus Posts en X, o Tweets en Twitter (como se día antes), a través de MyPublicInbox. Os cuento como funciona esto.

Figura 2: Premiar a tu comunidad por apoyos en X

Para premiar a los que apoyan a tus Posts en X, solo necesitas ir a Mi Impacto en Internet -> Twitter / X y tendrás las dos opciones. Si deseas premiar a tu comunidad, el funcionamiento es extremadamente sencillo, como ves aquí.

Figura 3: Funcionamiento de Tempos por Tweets

Basta con que copies el enlace al Post en X para el que quieres apoyos, y selecciones cuántos apoyos quieres, y qué cantidad de Tempos quieres repartir entre tu comunidad, como puedes ver aquí.

Figura 4: Apoyos a Posts en X

Si ya llevas utilizando un tiempo este servicio de apoyos, tendrás un grupo de personas que te "Apoyan Siempre", y lo harán de manera automática, así que rápidamente tu Post tendrá visibilidad y alcance en la red de X.

Figura 5: Estadísticas del servicio Tempos por Tweets

Además, si das a "Ver detalles", verás quién te ha apoyado, y tienes estadísticas de todos los apoyos que has recibido a lo largo del tiempo.

Apoyar a Perfiles Públicos y Ganar Tempos

Por otro lado, si lo que quieres es apoyar a Perfiles Públicos y Ganar Tempos, debes ir a Tempos -> Tempos Gratis -> Tempos por Tweets, y podrás ver las campañas de apoyo que están activas en este momento.

Figura 6: Servicio de Tempos por Tweets

Para poder apoyar a los Perfiles Públicos, primero deberás vincular tu cuenta de Twitter/X con MyPublicInbox, así que si no lo has hecho aún, tendrás una opción para hacerlo siguiendo este asistente.

Figura 7: Vincular tu cuenta de X con MyPublicInbox

Cuando la hayas vinculado, ya podrás Apoyar los Posts de X desde la plataforma, y podrás hacerlo una única vez, o Automática, apoyando siempre a todas las campañas de apoyo de ese Perfil Público que estás apoyando ahora.

Figura 8: Apoyo Simple o Apoyar Siempre

Y por supuesto, tendrás tus estadísticas de todos los apoyos que hayas realizado a lo largo del tiempo del servicio, y todos los Tempos que has ganado con tu cuenta de X en MyPublicInbox. Irás viendo como tus Tempos crecen día a día.

Figura 9: Estadísticas de Tempos por Tweets

Una vez que tengas los Tempos, los puedes usar para lo que quieras. Para canjearlos por libros de 0xWord, para canjearlos por bonos de descuento de entradas a eventos y cursos, para comunicarte con Perfiles Públicos, para convertirte en un Perfil Público, o para cualquier servicio de la plataforma.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Cómo funcionan los ataques de "Enjambre" de los C2C Traders en Wallapop o Ebay

noreply@blogger.com (Chema Alonso) — Sun, 23 Aug 2026 07:47:48 +0000

Hoy domingo quería dejaros otra cosa de esas que vivo con mis hijas. En este caso, sobre comprar y vender cosas en los Customer-to-Customer eCommerce (C2C), y la parte más difícil, poner el precio o saber si el precio que estás pagando es el correcto o no, y cómo manipular esto.

Figura 1: Cómo funcionan los ataques de "Enjambre" de los C2C traders

en los Customer-to-Customer eCommerce como Wallapop o Ebay.

Si te has ido a comprar un piso seguro que has mirado si está "caro" o "barato" para la zona. Las plataformas de compra y venta de pisos tienen para saber si está por encima de la media, en la media o por debajo. Es muy común y los especialistas de la "compra-venta", los traders, se conocen estos precios a la perfección. Sucede lo mismo con los de la cuadros de arte, cómics, cromos, libros antiguos, armas de coleccionista, o aparatos electrónicos.

Figura 2: Venta de Macintosh "Originales"

El negocio, como hacía el querido protagonista de "El Club Dumas", es saber lo que valen las cosas cuando compras y cuando vendes. Así, en esta novela, nuestro marchante de libros se dedicaba a ir a espoliar las bibliotecas de los fallecidos para localizar los incunables. Lo mismo lo hacen los traders del Wallapop, Ebay, y demás C2C. Buscan quién está vendiendo algo sin saber realmente lo que vale.

Figura 3: Información sobre el precio del Macintosh original

Hoy en día con la IA, puedes tener estimaciones y ayudas muy buenas para Comprar y Vender cosas a su precio correcto, y para no equivocarte en lo que compras y vendes, como en estes caso con un Macintosh Original, que su precio puede variar mucho, y te puedes llevar Classic o Plus por Original o SE por Original, si no conoces bien el producto. Curioso que en la búsqueda me saliera el enlace de nuestro blog de Seguridad Apple que hicimos en Informática64.

Figura 4: Ojo con el gato por liebre

Pero existe una cosa que hacen los menos experimentados en el noble arte de ganarse dinero sabiendo lo que valen las cosas. Son los que explotan la debilidad del propio usuario y del propio C2C de dar el precio medio en función de lo que valen los objetos similares que están a la venta.

Figura 5: Los Macintosh en Wallapop (Classics)

Para eso, utilizan su "Enjambre" de cuentas creadas, controladas, y manipuladas, que ponen a la venta los mismos objetos que quieren comprar, pero a los precios a los que los quieren comprar. Es decir, si desean comprar una Macintosh Original a 500 € y el vendedor lo tiene a 1.500 €, lo que hacen es que sus cuentas del enjambre comienzan a poner a la venta esos mismos Macintosh Original a 400 €, 600 €, 500 €, etcétera. Si el vendedor tiene ganas de vender pronto, sabrá que su producto tardará en salir si no sabe lo que realmente vale lo que vende.

Figura 6: Macintosh Original en Ebay

Así que, si vas a vender algo en un C2C, antes de ponerlo a la venta, averigua su valor, y ponlo correctamente sabiendo lo que haces. Estos "enjambres" se hacen también "preventivos", ya que se crean mucho antes de que aparezca el producto que quieren comprar, con la esperanza de que cuando alguien venga a vender, ponga el precio basado en los que ya están a la venta.

Figura 7: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

Y con el mundo Agentic AI, esto es una de las herramientas al alcance los Agentes IA que seguro que utilizarán. Que yo conozco a mucho "C2C trader" y se las saben todas...

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Cómo se desmontó el algoritmo que amenazaba a la Criptografía Post Cuántica 9 días después

noreply@blogger.com (Chema Alonso) — Sat, 22 Aug 2026 04:01:00 +0000

En el artículo anterior os contaba que el 6 de agosto de 2026 apareció en el archivo ePrint de la IACR un manuscrito de Daniel R. Simon, del grupo de Criptografía de AmazonWeb Services, que afirmaba haber resuelto en tiempo polinómico el Problema del CosetDiedral. Si aquello era cierto, por una reducción que Oded Regev demostró en 2004 caía en cascada la seguridad teórica de toda la familia de los retículos, y con ella la de ML-KEM y ML-DSA, es decir, la de los dos algoritmos que el mundo entero está desplegando ahora mismo para sobrevivir a la llegada de los ordenadores cuánticos.

Figura 1: Cómo se desmontó el algoritmo que amenazaba

a la Criptografía Post Cuántica 9 días después

Aquel artículo lo cerré en el peor momento posible: con el manuscrito recién colgado, la comunidad criptográfica abriéndolo en fin de semana y nadie en condiciones de decir todavía si aquello se sostenía o no. Lo que ocurrió a partir de ahí es, en mi opinión, bastante más interesante que el propio anuncio.

Figura 2: Los nueve días, de un vistazo. Del envío del preprint

al resultado de imposibilidad verificado por máquina

Así que os ahorro la intriga, porque el final no es lo importante: el trabajo no era correcto. Lo que merece la pena contar es cómo se demostró que lo era, en cuánto tiempo y con qué herramientas. Desde que el manuscrito se hizo público hasta que quedó formalmente descartado pasaron nueve días. Nueve. Sin comités, sin revisión por pares a seis meses vista y con todo el proceso a la vista de cualquiera que quisiera mirar.

Un recordatorio de treinta segundos: dónde estaba la dificultad

Para que lo que viene se entienda, hay que tener presente una sola idea del artículo anterior. En un algoritmo cuántico la respuesta casi nunca está guardada en un sitio concreto: está repartida en las fases relativas entre todas las ramas de la superposición. Es una propiedad del conjunto, no de ninguna pieza suelta.

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

Durante el cálculo se van acumulando restos, información residual enganchada al estado que hay que borrar para que las amplitudes puedan volver a interferir entre sí. Y ahí está el problema: si borráis esa basura midiéndola, os lleváis la fase por delante. Es como intentar desmontar el andamio de un edificio sin tocar el edificio. Regev resolvía esa papeleta suponiendo un oráculo de suma de subconjuntos, una caja negra que nadie sabe construir. La aportación de Simon consistía, precisamente, en prescindir de ella.

Retened la palabra andamio. Va a volver.

El fin de semana siguiente: la comunidad se pone a leer

Aquí es donde el episodio resulta más revelador, porque enseña cómo funciona de verdad la ciencia cuando nadie la está mirando desde fuera.

El manuscrito se hizo público un jueves. El fin de semana siguiente ya había criptógrafos leyéndolo con el lápiz en la mano y comentando en abierto lo que iban encontrando, y la discusión se concentró enseguida en unos pocos resultados intermedios del artículo, muy enparticular en el Lema 3.

No voy a poner aquí frases entrecomilladas ni a atribuir juicios técnicos concretos a nadie, porque buena parte de aquella conversación ocurrió en canales y foros que no dejan un enlace estable al que poder apuntaros, y prefiero no atribuir a un investigador una frase que no pueda enseñaros. Lo que sí podéis comprobar vosotros mismos, y no depende de que nadie os lo cuente, es lo que trae el propio manuscrito.

Figura 4: El Lema 3 del manuscrito de Simon, uno de los cuatro

resultados cuya demostración aparece marcada como ”(Sketch)”.

Fijaos en las dos palabras que siguen a ”Proof ”

Cuatro de los resultados que sostienen el teorema principal llevan sus demostraciones marcadas como ”(Sketch)”: el Lema 1 en la página 7, el Lema 3 en la 11, el corolario del Lema 3 en la 12 y el Lema 4 en la 13. El único de los lemas centrales que viene con demostración completa es el Lema 2. Dicho de otro modo: en un paper que reclama tumbar los cimientos de la Criptografía Post-Cuántica mundial, ninguna de las piezas críticas venía demostrada del todo. El 11 de agosto Simon subió una versión revisada del manuscrito, y esa es la que hoy encontraréis en ePrint. Cuatro días después llegó el golpe definitivo.

Figura 5: A Polynomial-Time QuantumAlgorithm for the Dihedral Coset Problem

Fijaos en un detalle que se pierde con facilidad: aquí hay dos modos de refutación encadenados, y son cualitativamente distintos. Primero, la comunidad encuentra errores en las demostraciones, que en principio son reparables. Después, tres investigadores demuestran algo mucho más fuerte. Ver las dos cosas ocurrir en menos de una semana, en abierto y a la vista de todos, es una lección de método científico que difícilmente encontraréis mejor contada en un libro de texto.

Día 15: no encontraron el error, demostraron que no hay arreglo

El 15 de agosto, Aparna Gupte (MIT), Seyoon Ragavan (Google Quantum AI y MIT) y Mark Zhandry (Google Quantum AI y Stanford) publicaron una nota demoledora. Y conviene fijarse bien en el matiz, porque es lo más importante de todo el artículo: No encontraron un error en la demostración. Demostraron que el algoritmo no puede funcionar.

Figura 6: ”The ePrint:2026/1591 Quantum Algorithm Does Not Solve DCP”,

la nota de Gupte, Ragavan y Zhandry

La diferencia es abismal: un fallo en una demostración se parchea, pero un resultado de imposibilidad no deja nada que parchear. Lo dicen ellos mismos en el abstract, sin rodeos:

”We are showing directly that the algorithm cannot possibly work”.

No están hablando del análisis que Simon hace de su algoritmo, están mostrando directamente que el algoritmo no puede funcionar.

¿Y cuál es el argumento? Volvamos al andamio.

Durante el proceso, el algoritmo genera unas etiquetas clásicas al aplicar la Transformada de Fourier, y las utiliza por última vez en el tercer paso del procedimiento, únicamente para calcular unos pocos bits altos de cada bloque. A partir de ahí no vuelven a aparecer.

Los autores demuestran que, en consecuencia, todo el estado del algoritmo se puede reconstruir con un error minúsculo, del orden de poly(n) 2−n/3, empleando solo el tercio más significativo de esas etiquetas. Dos tercios de la información se descartan por el camino. Y aquí está la clave: esas etiquetas eran precisamente lo que mantenía la coherencia entre las distintas ramas de la superposición, y en esa coherencia era donde vivía el secreto. El andamio era el edificio.

Figura 7: La idea del argumento. Mientras el algoritmo conserva

las etiquetas de Fourier, las ramas de la superposición mantienen

una relación de fase definida y el secreto es recuperable. Al

descartarlas, esa relación se pierde y con ella toda la información

El teorema que demuestran es además más general que el algoritmo de Simon: cualquier procedimiento que siga la plantilla de Regev y descarte suficiente información sobre esas etiquetas resulta incapaz de distinguir el último bit del secreto con ventaja apreciable, por sofisticado que sea el post-procesado posterior. No es que Simon lo hiciera mal: es que por ese camino no se puede pasar. Si habéis estudiado algo de física, el argumento os resultará familiar, porque es del mismo tipo que un límite fundamental de medida. Si la información ya no está en el sistema, no hay procesado que la recupere.

Figura 8: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Lo que el paper enuncia formalmente es una disyuntiva: o el algoritmo tarda del orden de 2n/9 en promedio para al menos uno de los dos secretos, o su ventaja al distinguirlos es a lo sumo poly(n) 2−n/9. Las dos cosas a la vez no pueden ser. Bernstein comprimió despuésesa disyuntiva en una sola cifra en su microblog: el cociente entre coste y probabilidad de éxito del algoritmo sería de al menos 2n/9. Exponencial, no polinómico.

Figura 9: Lo que el paper prometía frente a lo que la refutación demuestra.

Un algoritmo cuyo coste crece como 2n/9 no es un algoritmo eficiente

en ningún sentido útil de la palabra

Los autores son además escrupulosamente honestos: dicen que no conocen ninguna vía de reparación que esquive su teorema de forma significativa, pero se abstienen de afirmar que no exista. Y dejan una moraleja constructiva para quien quiera seguir intentándolo, que cualquier algoritmo para el DCP que siga la plantilla de Regev tendrá probablemente que usar las etiquetas de Fourier casi enteras durante la fase de descomputación.

Figura 10: Los agradecimientos de la nota que refuta el algoritmo.

El segundo nombre de la lista es el del autor del algoritmo refutado.

Y hay un último detalle que dice mucho de cómo funciona esta comunidad: en los agradecimientos de la refutación, los tres autores dan las gracias, entre otros, al propio Daniel R. Simon. No hay aquí ningún ánimo de humillar a nadie.

El detalle friki: la refutación viene con código (y con IA)

Llegamos ahora a la parte que a mí me parece la más significativa de todo el episodio, aunque no salga en los titulares. Gupte, Ragavan y Zhandry no se limitaron a publicar un PDF con su argumento. Publicaron también un repositorio con una especificación en Lean 4 del algoritmo de Simon y las demostraciones verificadas por máquina tanto del teorema principal como del corolario de imposibilidad. Cualquiera puede descargarlo, compilarlo y comprobar que el argumento cierra sin tener que fiarse de la buena fe de nadie.

Figura 11: El repositorio con la formalización en Lean 4

de la refutación, publicado junto con la nota.

Y no es una formalización de escaparate. En los 83 ficheros .lean del repositorio no aparece ni un solo sorry —la palabra con la que Lean marca un hueco que aún hay que demostrar— ni un solo axioma propio: cero objetivos sin resolver y cero atajos. Lo he comprobado clonando el repositorio y pasando el rastreo que los propios autores documentan en su README, que busca sorry, admit, axiom y compañía y debe salir vacío. Sale vacío. El mismo fichero añade una auditoría de axiomas del núcleo sobre los tres teoremas principales, cuyo resultado solo puede contener los principios lógicos estándar que Lean y Mathlib arrastran de serie —propext, Classical.choice y Quot.sound—, nunca uno inventado para la ocasión.

Y aquí se cierra el círculo con el que abría el primer artículo. En la declaración sobre uso de inteligencia artificial que incluyen en su nota, los autores cuentan que la versión general de su teorema(la que convierte una refutación puntual en un resultado de imposibilidad amplio) la encontraron conversando con modelos de lenguaje, y que emplearon esos mismos modelos para producir la formalización en Lean, asumiendo ellos toda la responsabilidad sobre la corrección del resultado. El propio README del repositorio lo repite en una sola línea: la formalización se preparó con ayuda de un modelo. No es una interpretación mía. Lo dicen ellos, con nombres y apellidos, en un párrafo del propio paper:

Figura 12: La declaración sobre uso de inteligencia artificial que acompaña

a la refutación. La versión general del teorema salió de una conversación

con modelos de lenguaje, y la formalización en Lean 4 también.

Merece la pena detenerse un momento en esto. Hace unas semanas os contaba en el en el artículo de "Claude Mythos Preview debilita los algoritmos criptográficos PQC HAWK y AES con nuevos ataques" que la IA había encontrado grietas reales en algoritmos criptográficos, y yo terminaba aquel artículo preguntándome qué pasaría el día que apareciese una grieta en un candado de verdad. Pues bien: la grieta llegó, y la IA no estaba en el bando que yo esperaba.

Estaba ayudando a demostrar que la grieta no existía. Ideas propuestas con ayuda de una máquina, verificadas por otra máquina, publicadas en abierto y todo ello en menos de dos semanas. Hace diez años esto habrían sido meses de correos cruzados entre departamentos de medio mundo. Si alguien os pregunta alguna vez para qué sirven los asistentes de demostración formal, este es el ejemplo que hay que dar.

Entonces, ¿hay que preocuparse?

La respuesta corta es que no. Los supuestos de dificultad sobre los que descansan ML-KEM y ML-DSA están exactamente donde estaban el 2 de agosto: ningún algoritmo estandarizado roto, ningún ataque calculado contra ningún conjunto de parámetros y ningún despliegue que haya que pausar.

La respuesta larga es más incómoda, y es la que de verdad deberíamos llevarnos a casa. Durante nueve días, mucha gente responsable de infraestructura crítica descubrió que su plan de migración postcuántica dependía por completo de una única rama de las matemáticas. Que el susto fuera falso no cambia el hecho de que era estructuralmente posible, y la puerta que Regev construyó en 2004 sigue ahí, abierta y señalizada. Que este intento de cruzarla haya fracasado no dice nada sobre el siguiente.

Figura 13: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

Por eso conviene fijarse en quién estaba mejor preparado. El BSI alemán lleva añosempujando la hibridación como norma —su posición es que la criptografía postcuántica se despliegue siempre junto a RSA o Curva Elíptica, no en solitario— y mantiene en su guía técnica esquemas ajenos a los retículos estructurados, como Classic McEliece, basado en códigos.

La ANSSI francesa va en la misma línea y considera la hibridación obligatoriadurante las dos primeras fases de la transición . Y el propio NIST construyó a concienciauna tubería de respaldo: seleccionó HQC en marzo de 2025 como alternativa basada encódigos frente a ML-KEM, y en mayo de 2026 hizo avanzar a tercera ronda a nuevecandidatos adicionales de firma. Ese último dato merece leerse despacio, porque es más elocuente de lo que parece.

Figura 14: Los nueve candidatos que el NIST pasó a tercera ronda en

su convocatoria defirmas adicionales, agrupados por familia matemática

De esos nueve, ocho no están basados en retículos. Hay isogenias (SQIsign),MPC-in-the-Head (MQOM, SDitH), multivariantes (UOV, MAYO, QR-UOV, SNOVA) yesquemas simétricos (FAEST). El único de la familia de los retículos era HAWK, y ya nisiquiera sigue en pie: su equipo lo retiró de la competición este mismo verano, después deque Mythos le encontrara una simetría oculta —un automorfismo no trivial en el retículo— que rebaja el coste de recuperar una clave de HAWK-256 de 2 elevado a 64 a 2 elevado a 38 y obliga a doblar el tamaño de clave para mantener el nivel de seguridad prometido. Si entráis hoy en la página del NIST, HAWK figura expresamente como retirado.

Dicho de otro modo: la tercera ronda de firmas adicionales del NIST es, a día de hoy, una ronda enteramente ajena a los retículos. La red de seguridad existe y está tejida a propósito, y el último hilo que quedaba de la familia sospechosa se soltó él solo apenas unas semanas antes de que Simon subiera nada a ePrint. Nadie podrá decir que no lo habían pensado. La pregunta abierta, y no es retórica, es si esa tubería se movería lo bastante rápido el día que la contingencia sea de verdad.

Conclusión

Este episodio no ha demostrado que la criptografía de retículos sea frágil. Ha demostrado algo mucho más valioso: que la comunidad que la vigila es rapidísima, transparente y capaz de autocorregirse en cuestión de días. Un investigador de primer nivel lanzó una piedra enorme al estanque, la comunidad se puso a leer el fin de semana, tres investigadores demostraron con ayuda de una máquina que la piedra no llegaba al fondo, publicaron la prueba en abierto para que cualquiera pueda compilarla, y le dieron las gracias al que la había tirado.

Eso es exactamente lo que uno espera de quienes custodian los cimientos matemáticos de Internet. La próxima vez, sin embargo, puede que la piedra sí llegue al fondo.Y entonces la pregunta ya no será si nuestros retículos aguantan, sino si tuvimos la prudencia de no apostarlo todo a una sola rejilla. Porque construir el futuro de la criptografía sobre un único pilar, por muy bien pintado que esté, sigue siendo construir sobre un único pilar. ¿Y si el próximo que venga a ponerlo a prueba no se equivoca?

Saludos,

Autor: Daniel Romero Ruiz

Figura 14: Contactar con Daniel Romero Ruiz

Otros artículos sobre Quantum Computing publicados:

El algoritmo que amenazó a la Criptografía Post-Cuántica

noreply@blogger.com (Chema Alonso) — Fri, 21 Aug 2026 04:01:00 +0000

Hace poco os contaba en este blog cómo una inteligencia artificial se había sentado, por primera vez y por derecho propio, en la mesa de los criptoanalistas en el artículo de "Claude Mythos Preview debilita los algoritmos criptográficos PQC HAWK y AES con nuevos ataques". Terminaba aquel artículo con una pregunta que entonces me pareció puramente retórica sobre si ¿estarán nuestros candados preparados para un mundo donde las máquinas buscan las grietas?

Figura 1: El algoritmo que amenazó a la Criptografía Post-Cuántica

No han sido las máquinas, pero la pregunta resultó tener una fecha de caducidad muy corta en forma de respuesta aviso. El susto llegó a principios de agosto de 2026, y de la mano de alguien a quien nadie en este campo puede tomarse a la ligera. Esta historia os la voy a contar en dos partes,

Figura 2: Amazon Researcher Claims Quantum Algorithm

Could Challenge PQC Foundations

La primera mitad de la historia, ésta, donde os voy a contar qué se anunció exactamente, por qué era tan serio y por qué, aun así, ninguna persona sensata salió corriendo a apagar los servidores. La segunda mitad de la historia, será sobre cómo la comunidad lo desmontó en nueve días, y con una ayuda bastante inesperada, y os la contaré en el próximo artículo.

El hombre que ya rompió la criptografía una vez

El autor del preprint no es un aficionado que ha leído tres entradas de la Wikipedia. Es Daniel R. Simon, del grupo de Criptografía de Amazon Web Services, y su apellido os resultará familiar si habéis pasado por cualquier curso de computación cuántica: en 1994 publicó el algoritmo de Simon, uno de los primeros resultados que demostró de forma limpia una separación exponencial entre lo que puede hacer un ordenador clásico y lo que puede hacer uno cuántico.

Figura 3: Problema de Simon

Aquel resultado no rompía nada por sí solo, porque el problema que resolvía era artificial, inventado a propósito para el argumento. Pero fue la chispa: Peter Shor lo leyó, entendió la maquinaria que había debajo y ese mismo año publicó su algoritmo, el que factoriza números grandes en tiempo polinómico y el que hará saltar por los aires RSA y la Criptografía de Curva Elíptica en cuanto tengamos la máquina cuántica.

Figura 4: Algoritmo de Shor en Wikipedia en Español.
Causante de que el RSA sea inseguro con la llegada de los ordenadores cuánticos

Tenemos, por tanto, a la persona que inspiró el algoritmo destinado a acabar con la criptografía actual regresando treinta y dos años después, esta vez sobre el sustituto. La simetría es demasiado buena para ser casualidad, y explica en buena medida por qué nadie se tomó este preprint a la ligera.

Un repaso rápido: por qué lo hemos apostado casi todo a una rejilla (los algoritmos lattice-based )

Los dos algoritmos de propósito general que el mundo entero está desplegando ahora mismo, ML-KEM (antes Kyber) y ML-DSA (antes Dilithium), pertenecen a la misma familia: los retículos. No es que el NIST no tuviera otras cartas —SLH-DSA, el antiguo SPHINCS+, se apoya solo en funciones hash y no toca un retículo ni de lejos—, pero el peso real de la migración recae sobre esos ML-KEM y ML.DSA. Y el tercer algoritmo que viene en camino, FN-DSA (el antiguo Falcon), también está basado e retículos, aunque de un tipo distinto.

Figura 5: 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

También es importante citar en esta parte de la historia a Frodo-KEM, que para librarse del "anillo" de los retículos por si algún día aparecía una debilidad matemática en ellos, hubiera otra alternativa. Por eso le llamaron Frodo, en honor a "Lord of the Ring", que es el hobbit más famoso de la historia luchando por librarse de un anillo.

Figura 6: Funcionamiento de Learning With Errors (LwE) de FrodoKEM

para evitar los retículos y que exista una alternativa para el KEM.

Un retículo es, en el fondo, una rejilla de puntos. Pensad en el papel milimetrado, pero en mil dimensiones y torcido, definido por una base de vectores que no son perpendiculares entre sí ni miden lo mismo. Sobre esa rejilla se plantean los dos problemas de siempre.

El SVP pide encontrar el punto más cercano al origen sin ser el origen: en dos dimensiones lo resolvéis mirando el dibujo, en mil y con una base torcida es una pesadilla. Y el LWE os entrega un puñado de ecuaciones lineales cuya solución es la clave secreta, pero con un ruido pequeño sumado a cada una: sin ruido lo resuelve un estudiante de primero con Gauss, con ruido se convierte en una sopa de letras.

La gracia de estos problemas es que generarlos resulta trivial, resolverlos parece imposible y, sobre todo, que nadie conocía un atajo cuántico. Shor destroza la factorización porque esta esconde una estructura periódica muy concreta que la transformada cuántica de Fourier detecta a la primera. Los retículos, en principio, no tienen esa estructura tan amable.

Figura 7: El mismo retículo con dos bases distintas: la ”buena” (vectores

cortos y casi perpendiculares) y la ”mala” (largos y casi paralelos).

Es la intuición clásica de por qué un retículo puede esconder un secreto, aunque conviene no tomarla al pie de la letra: la clave pública de ML-KEM no es literalmente una base mala, sino un sistema de ecuaciones con ruido

La puerta que Regev dejó construida en 2004

Aquí entra el protagonista técnico de la historia, con un nombre diseñado para espantar lectores: el Problema del Coset Diedral, o DCP por sus siglas en inglés. Conviene traducirlo.

Existe una familia enorme de problemas llamada problema del subgrupo oculto, y resulta que casi todos los grandes éxitos de la computación cuántica son casos particulares de ella. El algoritmo de Shor es un problema de subgrupo oculto sobre un Grupo Abeliano, es decir, conmutativo, de los ”fáciles”. El de Simon de 1994, también. Los ordenadores cuánticos son extraordinariamente eficaces en ese terreno, porque la transformada de Fourier diagonaliza esos grupos y la interferencia se encarga del resto.

El grupo diedral (el de las simetrías de un polígono: rotaciones y reflexiones) no conmuta. Girar y luego reflejar no es lo mismo que reflejar y luego girar, y ahí es donde el método se atasca. En su versión de Coset, el problema queda planteado así: recibes muchísimos estados cuánticos, cada uno de ellos una superposición de | 0, x ⟩ y | 1, x + s ⟩, con x distinto en cada muestra y s un valor secreto que se repite en todas. Tu misión, si decides aceptarla, es recuperar s.

Figura 8: On Lattices, Learning with Errors,

Random Linear Codes, and Cryptography.

¿Y qué tiene esto que ver con los retículos? En 2004, Oded Regev demostró una reducción: quien supiera resolver el DCP de forma eficiente, sabría resolver ciertos problemas difíciles de retículos. Esa reducción es incondicional, no depende de ninguna suposición extra, y en 2018 Brakerski, Kirshanova, Stehlé y Wen la afinaron todavía más, conectando el LWE con una variante extrapolada del mismo problema diedral. La puerta llevaba veinte años construida y señalizada.

Figura 9: Order-LWE and the Hardness of Ring-LWE with Entropic Secrets

Lo que faltaba era la llave: un algoritmo eficiente para el DCP. Y aquí es donde aparece el famoso oráculo, que conviene situar bien porque medio Internet lo colocó en el sitio equivocado. En un trabajo distinto del anterior, el propio Regev dio también un procedimiento en tiempo polinómico para resolver el DCP, pero suponiendo acceso a un oráculo de suma de subconjuntos: una cajita mágica capaz de resolver otro problema difícil que nadie sabe resolver. Es como decir que sabes llegar a Marte suponiendo que alguien te presta una nave que llega a Marte.

Figura 10: A subexponential-time quantum algorithm for

the dihedral hidden subgroup problem

Fijaos bien en dónde queda el hueco, porque es la clave de todo: el tramo que va del DCP hasta los retículos está entero. Lo que nadie tenía era la primera pieza, un algoritmo real para el DCP. Y el mejor conocido, el de Greg Kuperberg (2005), corría en tiempo subexponencial: mucho mejor que la fuerza bruta, pero muy lejos de polinómico.

Figura 11: La cadena que preocupa a los criptógrafos desde 2004.

El tramo que va del DCP hasta ML-KEM y ML-DSA está completo y demostrado; la pieza que faltaba estaba justo antes, un algoritmo eficiente para el DCP que no dependiese de un oráculo

Lo que decía el paper: quitar el andamio sin tirar el edificio.

El 3 de agosto Simon subió a ePrint un manuscrito titulado "A Polynomial-Time QuantumAlgorithm for the Dihedral Coset Problem". La IACR lo aprobó y lo publicó el día 6 de Agosto, que es cuando la prensa especializada se hizo eco, y el paper fue revisado el día 11 de Agosto. Lo que afirmaba era exactamente la llave que faltaba: resolver el DCP en tiempo polinómico sin necesidad del oráculo.

Figura 12: A Polynomial-Time QuantumAlgorithm for the Dihedral Coset Problem

La dificultad que hay que salvar es más sutil de lo que parece, y merece la pena entenderla bien, porque va a ser la clave de todo lo que os cuente en el próximo artículo. En un algoritmo cuántico la respuesta casi nunca está guardada en un sitio concreto: está repartida en las fases relativas entre todas las ramas de la superposición. Es una propiedad del conjunto, no de ninguna pieza suelta. Y a lo largo del cálculo se van acumulando restos, información residual enganchada al estado que hay que borrar para que las amplitudes puedan volver a interferir entre sí. El problema es que, si borráis esa basura midiéndola, os lleváis la fase por delante. Es como intentar desmontar el andamio de un edificio sin tocar el edificio.

Figura 13: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

La propuesta de Simon consistía en dividir las muestras en bloques y procesarlos de forma que unos quedasen limpios de fases indeseadas mientras los demás se apartaban dejando el estado casi equilibrado. Después se transfiere a un qubit de repuesto la fase que codifica un bit del secreto y se repite el proceso de manera recursiva.

Figura 14: El problema de fondo: la respuesta no está en ninguna rama concreta de la superposición, sino en la relación de fase entre todas ellas. Borrar la información sobrante sin destruir esa relación es lo que Regev solo sabía hacer con un oráculo.

El artículo subrayaba además un detalle: el algoritmo afirmaba tolerar muestras defectuosas hasta una tasa de 1/O(log n). La idea es que las reducciones que van desde los retículos hasta el DCP pueden introducir ese tipo de basura, y el algoritmo de Kuperberg exige muestras limpias.

Conviene decir, eso sí, que este punto fue discutido de inmediato: Elena Kirshanova, coautora del trabajo de 2018 sobre el que se apoya toda la reducción, señaló que la tolerancia al ruido no llega a usarse en ningún momento del paper, porque las reducciones existentes ya entregan muestras limpias en cantidad polinómica. Y la razón de fondo por la que el algoritmo de Kuperberg nunca inquietó a nadie es más simple: es subexponencial, y punto.

Con oráculo o sin él, el corolario final afirmaba resolver en tiempo polinómico aproximaciones al SVP con factor √n polylog(n) e instancias de LWE en el régimen equivalente. Traducido:

Un ordenador cuántico podría atacar de forma eficiente el problema que sostiene buena parte de la criptografía postcuántica.

Y aquí un detalle que parece menor y que va a resultar decisivo en el próximo artículo: ese corolario final, el que fija los parámetros concretos de SVP y LWE, no venía derivado en el manuscrito, sino atribuido a comunicaciones personales con Daniele Micciancio y Seyoon Ragavan. Guardad ese segundo nombre.

Por qué nadie salió corriendo a apagar los servidores

Y sin embargo la reacción de la comunidad no fue el pánico, sino una mezcla muy saludable de ”esto es enorme” y ”conviene mantener la calma”. Merece la pena entender por qué, porque aquí hay una lección práctica sobre cómo leer titulares tecnológicos.

1. Aproximado no es exacto: El resultado no encontraba el vector más corto, sino uno razonablemente corto. De ahí a ”te recupero esta clave de ML-KEM” hay un trecho considerable.

2. Peor caso frente a caso medio, y una capa más: Los problemas de retículos que aparecen en las reducciones son de peor caso; los que protegen vuestro navegador son instancias medias con parámetros muy concretos. Y hay un salto adicional: ML-KEM y ML-DSA no descansan sobre LWE a secas, sino sobre Module-LWE, que arrastra estructura algebraica extra.

3. Polinómico no significa práctico: El propio análisis del paper exige una constante c ≥12, lo que se traduce en del orden de n13 muestras. Comparadlo con el coste cúbico del algoritmo de Shor. Un polinomio de grado trece es polinómico igual que ir andando a la Luna es una distancia finita.

4. No había estimación de recursos: Ni qubits lógicos, ni puertas, ni profundidad de circuito, ni operaciones corregidas de errores. Nada.

5. Era un preprint: Sin revisión por pares, con el propio autor calificándolo de preliminar en el título, con cuatro de sus lemas presentados explícitamente como esbozos ”Proof. (Sketch)”.

Al segundo punto, eso sí, le habían quitado bastante fuelle apenas unos días antes, y esto casi nadie lo contó. Weiqiang Wen y Jinwei Zheng, de Télécom Paris, publicaron un trabajo ya revisado por pares y aceptado en CRYPTO 2026 en el que demuestran una equivalencia cuántica en tiempo polinómico entre Module-LWE y una variante estructuradadel problema diedral extrapolado.

Figura 15: Module Learning With Errors and

Structured Extrapolated Dihedral Cosets

Wen es coautor del artículo de 2018 sobre el que se apoya la reducción de Simon, así que no hablamos de dos grupos que llegan por casualidad al mismo sitio, sino de la misma línea de investigación avanzando. El puente hasta el supuesto de dificultad que hay debajo de ML-KEM era, de repente, más corto de lo que parecía la semana anterior.

Quien sí quedaba fuera de esta vía concreta es FN-DSA (el antiguo Falcon), que se apoya en retículos NTRU y para el que no se conoce ninguna reducción publicada que lo conecte con el DCP. Si el resultado hubiera sido correcto, habría supuesto un avance mayúsculo de complejidad teórica y un aviso muy serio sobre los cimientos. Pero no era un ataque: nadie tenía motivos para detener su migración a ML-KEM, y a día de hoy sigue sin haberlos.

Y entonces la comunidad se puso a leer

Un preprint de este calado no se queda quieto mucho tiempo. El fin de semana siguiente a su publicación, criptógrafos de primer nivel ya tenían el manuscrito abierto y el lápiz en la mano, y para el 15 de agosto el asunto estaba cerrado.

Figura 16: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

Lo interesante no es que encontraran un error. Es que hicieron algo bastante más definitivo, y lo hicieron con una herramienta que hasta hace muy poco no habría estado sobre la mesa. Pero eso, junto con la respuesta a la pregunta con la que abría este artículo, os lo cuento en el próximo.

Saludos,

Autor: Daniel Romero Ruiz

Figura 14: Contactar con Daniel Romero Ruiz

Otros artículos sobre Quantum Computing publicados:

Guía de Seguridad de un Hacker para personas que no quieren ser Víctimas

noreply@blogger.com (Chema Alonso) — Thu, 20 Aug 2026 07:07:38 +0000

Hace años que aprendo con César Cerrudo. Un hacker de la old-school al que admiro y quiero, así que hoy quiero dedicarle el artículo a su proyecto de la "Guía de Seguridad de un Hacker", donde ha invertido tiempo en construir un libro gratuito con la misión de llegar a 1.000.000 de personas y lograr que dejen de ser víctimas en Internet de los estafadores, ciberciminales y, como dice él en muchas de sus charlas, "malas hierbas".

Figura 1: Guía de Seguridad de un Hacker para personas que no quieren ser Víctimas

En palabras del propio César Cerrudo: "Hice una nueva versión del libro de ciberseguridad. Agregue un nuevo capítulo de inteligencia artificial, simplifique algunas cosas, mejore otras, etcétera. Como mi objetivo siempre fue que llegue a la mayor cantidad de gente posible decidí que lo mejor era publicarlo gratis para descargar online en PDF y ebook con licencia creative commons para que cualquiera pueda usar el material también (personas, empresas, organizaciones publicas, ONGs, etcétera) e imprimirlo si alguien quiere un libro impreso."

Figura 2: Contenidos del libro

El libro viene acompañado de muchos recursos para aprender cosas básicas y protegerse mejor en el uso de la tecnología, tiene infografías, tiene presentaciones para niños y adultos por si alguien quiere ayudar en escuelas, organizaciones, empresas, etcétera, enseñando.

Figura 3: Contactar con César Cerrudo

También hay un test interactivo online para ver qué tan seguro es alguien, otro para detectar y simular trampas y una mini academia para aprender en unos pocos minutos cosas básicas.

Figura 4: La mini-academia de Guía de Seguridad de un Hacker

Y en los tests online, puedes probar a cualquiera si está o no preparado para detectar las amenazas del mundo de hoy, y aprender cómo se construyen estos mensajes, como puedes ver en el siguiente ejemplo.

Figura 5: Aprendiendo de Phishing

No hace falta que te diga que te lo recomiendo, ya que como siempre he dicho, César Cerruro es uno de los grandes de nuestra generación, y eso lo puedes leer hasta en la web de dónde puedes descargarte el libro de Guía de Seguridad de un Hacker.

Figura 6: Chema Alonso dixit

El objetivo que se ha marcado César Cerrudo es conseguir llegar a 1 Millón de personas, así que si lo descargas, lo lees, lo compartes, lo promocionas, lo recomiendas, para que todo el mundo esté más seguro, ayudarás en esta misión.

Figura 7: Descargar el libro gratis

Recuerda, no es un libro para expertos, es un libro para todo el mundo. Para evitar que tu familia, tus padres, tus amigos no técnicos, caigan en este tipo de amenazas. Y hay un capítulo nuevo dedicado íntegramente a las estafas con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Aún un poco más difícil

noreply@blogger.com (Chema Alonso) — Wed, 19 Aug 2026 04:01:00 +0000

Cuando aún guardaba algo de tiempo para jugar al ordenador, me gustaban mucho los juegos de carreras de coches y de motos. No exigían mucha información previa para saber qué es lo que había que hacer. Ir rápido. Correr mucho en las rectas, y no peder agarre en las curvas. Sencillo. Claro, la complejidad consistía en tener la destreza para hacerlo mejor vuelta a vuelta. Como un martillo. Como un cronómetro repetitivo que cada vez te exige hacerlo mejor.

Figura 1: Aún un poco más difícil

De esos juegos había una cosa que acababa por desesperarme. Competir contra mi "shadow". Es decir, el "fantasma" de tu coche o tu moto en tu mejor vuelta. Superarlo era cada vez más difícil. Era luchar contra uno mismo. Hacerlo mejor. Y era más difícil vencerle cada vez. Es luchar contra ti mismo. Contra quién eres. Pero yo me encabezonaba en hacerlo más difícil aún cada vez que lo ganaba. Subía el record de mi vuelta y me costaba más vencer al fantasma a partir de ese momento.

En mi vida profesional he hecho lo mismo siempre. El más difícil todavía. Cómo puedo hacerlo mejor aún de lo que lo he hecho el año pasado. Cómo puedo vencer al yo del año anterior. Qué puedo estudiar nuevo, qué puedo certificarme, qué puedo lanzar, qué cosa puedo hacer aún mejor de lo que ya lo hacía. Así comienzo cada primero de año. Con esas cosas en mi cabeza. Hago balance en Diciembre, me pongo metas en Enero.

Soy así. Qué le voy a hacer....

Por eso en estudios hice EGB, BUP, COU, Ingeniería Técnica de Sistemas, Ingeniería Superior, Master, Doctorado. Mientras hubiera algo que pudiera mejorar no iba a descansar. Pero también lo hice con las certificaciones profesionales de Microsoft. Y el CAP para dar clases en Institutos (estuve dando clases). O ser el director del Máster de una universidad por 10 años. Todos los fines de semana. Y también con montar empresas. Informática 64, ElevenPaths, LUCA, 0xWord, MyPublicInbox. y también en hacer cada vez más y más proyectos de hacking. Y dar conferencias por todo el mundo. Dar ocho charlas en DefCONs, varias BlackHats y más de doscientas conferencias en eventos de todo el mundo. ¿Por qué no? O hacer radio. O escribir un nuevo libro. Entrevistas. Podcasts. Y hacer patentes. Whitepapers. Es interesante. ¿Por qué no?

Y también en el blog ¿a ver cuantos días seguidos aguantas sin fallar un día sin postear? Y llevo ya una racha de más de 1.000 días seguidos.

Tiene que ser el más difícil todavía. Tengo que mejorar mi pobre Inglés. Y aprender Portugués. Y centrarme en saber lo más que pueda de IA. Pero sin dejar de lado el mundo del Quantum Computing. O la Web3. Y meterme en saber cómo va la robótica, la computación óptica, o cómo funcionan los algoritmos de cifrado post-cuántico. Pero también tengo que estar al día, y leerme los papers que voy seleccionando. Y tener más fuentes de información.

Cada vez estiro más la densidad de cosas que hago por unidad de tiempo. Porque quiero hacer el más difícil todavía para mí. No para vosotros. No para nadie. Soy yo jugando con la sombra en el juego de carreras. Esto compitiendo conmigo mismo. No me importa si los demás van por delante, por detrás o al lado. Soy mi peor enemigo. Soy yo luchando contra la mejor versión de mí que haya tenido alguna vez. Un jugador compitiendo contra sí mismo.

Con esta forma de funcionar, es normal que naciera MyPublicInbox y los Tempos. Mi tiempo lo valoro como nada. Poner tiempo en algo es quitárselo a otro. Esto me llevó a dejar de clasificar el correo electrónico y dejar de mirar el reloj. Perdía tiempo mirando el reloj, así que será raro que hoy en día me veáis con un reloj. Tengo poco tiempo que perder con las rutinas que tengo metidas en mi vida.

También me quité las redes sociales, la televisión, o las series enormes. No, no es me haya quitado el cine, sino que me gustan mis cosas. Mis libros, mis cómics, mis películas de superhéroes y ciencia-ficción, así que no veo mucha tele, series largas, o películas "por probar". Nop. A tiro hecho.

Al final es una competición de priorizar el uso del tiempo. No se puede todo. Y puedo que algún día decida reducir mi inversión en este blog, o en dar charlas, o en trabajo, y me dedique solo a lo que más me guste. No olvidéis que también me gusta patinar, hacer deporte, y salir con la bici, estar con los amigos, salir a cenar a una azotea, ver la noche y tomarme un vino. Y si el tiempo lo permite, viajar.

De aquellos años de jugar contra mí a las carreras de coches y motos aprendí el concepto de límite asintótico. Hay un punto en el que el intentar hacerlo más difícil todavía, es decir, tomar una curva apurando más la frenada, acelerar más en la chicán, o intentar adelantar en la zona equivocada puede llevarte a accidentes y desastres, así que sé que tarde o temprano, en cada una de las líneas de interés, tengo que decir: "Hasta aquí di de mí". Y hacer otra cosa.

Pero mientras sea así, yo escribo todos los días mi post. Para hacerlo aún mejor que lo hice el año anterior. Para subir mi record de días consecutivos publicando. Porque quiero seguir mejorando. Lo quiero hacer porque me hace sentirme bien. Trabajo la resiliencia, el esfuerzo, la disciplina, el aprendizaje, la comunicación, y además hago amigos y disfruto de mi trabajo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

La Enciclopedia Mecánica: El libro eléctrico, mecánico y a presión de aire creado en España en 1949

noreply@blogger.com (Chema Alonso) — Tue, 18 Aug 2026 06:41:15 +0000

Hoy os voy a hablar de un interesante artefacto, hecho en España y que se conoce como la Enciclopedia Mecánica de Ángela Ruiz Robles, un invento que se considera el primer prototipo del libro digital. Un "gadget" que se diseñó para educar a niños. Y es que la Enciclopedia Mecánica se creó con el objetivo de facilitar la enseñanza.

Figura 1: La Enciclopedia Mecánica: El libro eléctrico, mecánico

y a presión de aire creado en España en 1949

Era un libro mecánico, eléctrico y a presión de aire para lectura de libros. Se componía de unas bobinas pequeñas intercambiables con información y dibujos de cada asignatura. Las bobinas iban pasando manualmente mediante unos pulsadores debajo de una lámina transparente con cristal de aumento.

Figura 2: La Enciclopedia Mecánica

Estaba también dotada de luz, sonido y un abecedario automático con letras y números accionados mecánicamente, para escribir palabras o hacer cuentas. La Enciclopedia Mecánica de Doña Angelita tenía el tamaño de un libro y se realizó con materiales ligeros (bronce, madera, zinc y papel).

Figura 3: Tamaño de la Enciclopedia Mecánica de Doña Angelita

Estaba pensada para facilitar el aprendizaje, se colocaba en un maletín y los alumnos podían llevar las bobinas de cada asignatura, con lo que irían con mucho menos peso al colegio. Su autora Ángela Ruiz Robles (1895-1975) la creó en 1949 y la patentó como diseño en en la patente número 190.698, que luego convirtió en un prototipo patentado en 1962 (Patente 276.346 )

Figura 4: Angelita Ruiz Robles con su Enciclopedia Mecánica

Si tenéis curiosidad por saber cómo funcionaba podéis ver una infografía hecha por la Fundación Telefónica que os dejo por aquí . Y si queréis verla en directo podéis encontrarla en el Museo Nacional de Ciencia y Tecnología de A Coruña.

Figura 5: Infografía hecha por la Fundación Telefónica

Su inventora Ángela Ruiz Robles (1895-1975) era maestra, pedagoga, educadora, inventora y empresaria. Tenía una fuerte vocación por la enseñanza, compaginaba su trabajo con su propia academia para adultos Elmaca (las iniciales del nombre de sus tres hijas) de Ferrol.

Figura 6: Retrato de Ángela Ruiz Robles, dibujado y pintado

por la artista argentina Eulogia Merle

Impartía clases particulares a oposiciones de Aduanas, Correos, Telégrafos y examen de ingreso a las Escuelas de Altos Estudios Mercantiles. Aquí tienes la Patente 276.346 que recoge la invención, de 1962.

Figura 7: Patente de la Enciclopedia Mecánica

También escribió 16 libros. Fue una visionaria adelantada a su época, tenía una visión nueva respecto a la educación, quería convertir la en un proceso más humano, más fácil atractivo y visual. Y con su Enciclopedia Mecánica lo consiguió.

Saludos,

PD: Aprovecho para deciros que hoy cumplo un sueño, y es escribir un post en El Lado del Mal, sigo a Chema Alonso desde 2017 y para mí es toda una inspiración.

Autor: Marta Tobarias

Contactar con Marta Tobarias

Pensamientos Robados: Cómo descifrar y weaponizar trazas de razonamiento en LLMs

noreply@blogger.com (Chema Alonso) — Mon, 17 Aug 2026 04:01:00 +0000

Este domingo, aprovechando un poco de la tranquilidad del día, me he leído el trabajo de Stolen Thoughts, que explica cómo descifrar las trazas de razonamiento de los modelos LLM frontera que se entregan cifradas a los clientes, durante el proceso de resolución de un Prompt complejo que exige una cadena de pensamientos (Chain-of-Thoughts).

Figura 1: Pensamientos Robados - Cómo descifrar y

weaponizar trazas de razonamiento en LLMs

Justo de estas trazas que van cifradas, es de lo que trata el paper del que os hablo en este artículo, titulado: "Stealing Reasoning Traces from Proprietary LLM APIs" y que ha puesto de manifiesto cómo esta debilidad se puede utilizar de formas muy curiosas.

Figura 2: Stealing Reasoning Traces from Proprietary LLM APIs

Supongo que alguna vez habréis usado ChatGPT, DeepSeek, Claude o Gemini, y habréis visto las trazas de razonamiento ir saliendo por pantalla. Esto lo utilizamos para aprender cómo está razonando, y sobre todo para saber si tu idea va por el lado correcto o no. En el trabajo de "Estego & Cripto sólo al alcance de Deep Reasoning AI" para nosotros era fundamental, ya que podríamos saber si el modelo estaba por el buen camino o no, para resolver las codificaciones cifradas.

Figura 3:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Lo que sucede es que estas trazas de razonamiento, es decir, estas Chain of Thoughts que se entregan a los clientes, no se muestran todas, y algunas van cifradas en variables. Estas variables son enviadas desde el cliente al servidor, donde son descifradas y utilizadas como contexto, para seguir razonando. Es decir, que el servidor sabe descifrar estas trazas.

Figura 4: Encrypted Thought Injection

Sabiendo esto, lo que los investigadores han hecho es lo que llaman un ataque de Encrypted Thought Injection, de un modelo, a otro modelo de la misma empresa que tienen medidas de seguridad inferiores. Por ejemplo, como se ve en la imagen anterior, se coge la traza cifrada del Chain of Thoughts que devuelve la API de Claude Opus y se inyecta en una petición a Claude Haiku 4.5 pidiéndole que lo transcriba y lo imprima. Y lo hace.

Figura 5: Compatibilidad en Chain of Thoughts cifrados entre modelos.

Los investigadores han visto cual es la compatibilidad que Claude, GPT o Gemini tienen en sus diferentes versiones, y como se puede ver es bastante alta, así que es posible mover Stolen Thoughts de uno a otro modelo. Haciendo esto, se pueden encontrar datos personales, o prohibidos por el modo Harmful Mode, como en el ejemplo siguiente, donde se encuentran datos de marcas de vehículos y facilidad de ser robados, que sólo están en los "pensamientos" cifrados.

Figura 6: Datos sobre marcas de vehículos que sufren más robos.

Estas trazas de razonamiento se cifran por motivos diversos, pero también para evitar el Destilado, o lo que es lo mismo, que un modelo Open Source - o no - pueda utilizar Prompts y trazas de razonamiento completo para hacer un Fine-Tuning de su comportamiento a partir de la capacidad de inteligencia de un modelo comercial de frontera, que es una de las formas de optimizar costes, como os conté en el artículo de: "Cómo optimizar el gasto en IA con arquitecturas clasificadas, orquestadas y/o destilación. El problema de la Predictibilidad de los Costes de la IA".

Figura 7: Destilación de Modelos

Sin embargo, estos Thoughts cifrados pueden ser utilizados como "Pre-fill" a un modelo. Es decir, utilizar el Encrypted Thought Injection Attack de un modelo frontera a un modelo Open Source para pedirle que continúe resolviendo el problema.

Figura 8: Pre-filling de Thoughts

Esto puede utilizarse para "enfocar" la resolución del problema con un Modelo Frontera, y luego continuar con el resto del problema a partir del Pre-fillling. Como podéis ver en la imagen, Kimi-K3 con el Pre-filling da un resultado similar. El proceso es capturar la traza cifrada, descifrarla con un modelo compatible que lo pueda descifrar y luego inyectar el pensamiento descifrado en el modelo Open Source para terminar de resolver el Prompt. Creativo.

Figura 9: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

El paper muestra más usos de esta capacidad de descifrar las trazas de pensamiento cifrado, pero también que en ellas, cuando una persona comparte sus conversaciones, pueden ir datos privados, como API Keys o Passwords, así que hay que tener mucho cuidado con publicar estos datos de las APIs con las trazas cifradas.

Figura 10: Trazas cifradas con API Keys y Passwords

La verdad es que me ha parecido muy interesante el trabajo, que parte de una idea muy sencilla, que es utilizar modelos LLM compatibles con menos protecciones para descifrar los Thoughts cifrados que te da el LLM frontera. Muy hacker.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

La Policía Nacional detiene a un cibercriminal que usaba DeepFakes para obtener Certificados Digitales gracias a un Glitch

noreply@blogger.com (Chema Alonso) — Sun, 16 Aug 2026 06:23:00 +0000

En el año 2017, cuando descubrí los primeros ejemplos de técnicas de FaceSwapping, mi mente viajo al futuro y pensé en el mundo de los Blade Runners y Replicantes Virtuales, pero en el mundo digital. La capacidad de llevar "máscaras digitales" al estilo de la película "Desafío Total (Total Recall)", cruzaba por mi cerebro. Sí, la ciencia ficción siempre me llena la cabeza de posibles futuros que pueden venir detrás cuando veo una nueva innovación.

Figura 1: La Policía Nacional detiene a un cibercriminal que usaba

DeepFakes para obtener Certificados Digitales gracias a un Glitch

Durante esos años, comenzamos a trabajar mucho en el equipo de Ideas Locas con las técnicas de FaceSwapping, los Autoencoders, las herramientas para hacer DeepFakes, y las técnicas de detección. El famoso Test de Voight-Kampff digital que tanta falta sabíamos que hacía, especialmente para un mundo que se estaba yendo a 100% digital, y donde los procesos de Know-Your-Customer (KYC) debían hacerse totalmente online.

Figura 2: Técnicas de IA en ciberseguridad y su impacto en Deepfakes

Hoy en día, las técnicas de DeepFake son de gran calidad, y los cibercriminales, los estafadores en las redes sociales, y los APTs a las organizaciones las tienen como una herramienta más. En el mundo del uso de la IA para el Cibercrimen, como os conté en el artículo de "Weaponized AI", las herramientas para generar identidades digitales con DeepFake totalmente identificados, documentadas y funcionales, es una pieza más del sistema.

Figura 3: Vídeo de Haotian AI. DeepFake de Vídeo y Voz

Que sean tan perfectas las herramientas exige en los entornos de alta necesidad de seguridad que estas identidades sean verificadas de formar remota con una gran robustez, si no, se podría estar poniendo a los cibercriminales las cosas sencillas. Por supuesto, entornos de banca, o, como en este caso, Entidades Certificadoras Autorizadas que entregan Certificados Digitales asociados a una Identidad Verificada - por su DNI y su Prueba de Vida - en un proceso de KYC, necesitan, obligatoriamente usar técnicas avanzadas de detección de DeepFakes.

La Policía Nacional detiene a un ciberdelincuente que utilizaba una técnica pionera mediante IA para obtener certificados de firma electrónica

La Policía Nacional, publicó en su Sala de Prensa el pasado 11 de Agosto como habían detenido a un cibercriminal que se había dedicado a sacarse más de 30 Certificados Digitales conseguidos en más de 38 intentos en un Entidad Certificadora Autorizada en España usando, para ello técnicas de DeepFake, trabajadas con iluminación, y documentos falsos que debía mostrar a la cámara.

Figura 4: La Policía Nacional detiene a un ciberdelincuente que utilizaba una

técnica pionera mediante IA para obtener certificados de firma electrónica

El cibercriminal creaba primero la identidad, sobre ella creaba unos documentos de identidad falsos, y luego hacía el proceso de Know Your Customer onnline con sofisticadas técnicas de iluminación para conseguir reproducir los destellos de los hologramas y las medidas de seguridad físicas de los DNIs, asociando el uso del programa de DeepFake al mismo tiempo para salir en vídeo.

Por supuesto, su red de anonimato iba mucho más allá, ya que tenía 320 líneas telefónicas, asociadas a 24 dispositivos móviles distintos, de los cuales la gran mayoría eran contratadas con identidades suplantadas y adquiridas en puntos de venta geolocalizados en Murcia, de donde es el cibercriminal.

Figura 5: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

En las empresas, los ataques a las organizaciones con empleados falsos empiezan a hacer esto. Primero poner a personal altamente cualificado para pasar el proceso de entrevistas. Hacen un currículo con IA que responda perfectamente a la oferta en concreto - siempre buscando trabajar en remoto - y luego pasan los procesos de selección y onboarding con estas técnicas, para luego dejar el equipo en una granja de ordenadores conectados a empresas que los atacantes pueden utilizar aprovechando las credenciales que la organización le ha entregado.

Figura 6: Glitch en Wikipedia ES

En este caso, todo iba bien, hasta que en uno de los procesos, por la iluminación, un fallo en el equipo, o por simplemente el azar, el software de DeepFake sufrió un Glitch, es decir, un fallo momentáneo como los que tiene nuestra querida Vanellope von Schweetz en la película de Rompe Ralph, y el proceso de Know Your Customer grabó su imagen por un segundo. Si no... difícil cada vez más detectar a estos "Replicantes Digitales".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

El "Trick" del comprobante del Bizum hecho con IA para "ratear" un pago a los colegas

noreply@blogger.com (Chema Alonso) — Sat, 15 Aug 2026 04:01:00 +0000

Hace unos años os conté la historia de "El "jeta" del "Yo Pago" con el Apple Pay que es un ScreenShot" donde un "amigo" simulaba tirar de tarjeta con una captura de pantalla. Hoy sábado, os traigo otra historia que me ha llamado la atención porque me la contó mi hija, donde se ve como los "jetas" aprenden nuevas formas de "ratear" pagos, en este caso con el comprobante de Bizum hecho con IA.

Figura 1: El "Trick" del comprobante del Bizum hecho

con IA para "ratear" un pago a los colegas

Esta historia me la contó Mi Hacker, y me hizo mucha gracia. Parece ser que entre su grupo de amigos alguno/a había utilizado este truco de hacer un comprobante falso con GenAI para enviarlo como justificante de que ha pagado su parte.

Figura 2: Un comprobante de Bizum real

Pero especialmente para cuando un "papá" - y remarco lo de "papá", ha hecho el pago y tiene que recibir el Bizum de otro "papá", ya que parece que las "mamás" lo comprueban más. Alguien paga una cena, unas entradas, o cualquier otra cosa en grupo, y luego los demás ponen su parte a través de Bizum. Algo muy común en nuestra vida.

Figura 3: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

En la de los adolescentes es "mi papá le hace Bizum al tuyo". Así, el padre del pagador, supuestamente hace el Bizum, le manda el justificante a la amiga o amigo, y todos tan contentos.

Figura 4: Pidiendo la falsificación del precio a Gemini Nano Banana

El "Trick" es que el Comprobante de Bizum es falso. Se podría haber hecho con Photoshop, o con cualquier otra herramienta, pero con el acceso a la IA, todos los adolescentes directamente le piden que les haga los comprobantes y listo.

Figura 5: Razonamiento de Gemini Thinking

Yo lo he querido probar con Gemini Nano Banana, por si había algún control al detectar que era un justificante de pago o similar - como sucedía con el test de COVID -, pero no da ningún problema, y de hecho se esfuerza y mucho por dejarlo todo en su sitio.

Figura 6: Dejándolo perfecto.

El resultado, pues lo que ya imaginamos, que sale un comprobante perfecto pero con otro precio manipulado. Y si ya sabes que funciona, pues le modificas lo que quieras en la próxima. La fecha, el concepto, el destinatario, el precio, etcétera.

Figura 7: El resultado final. Un comprobante de Bizum manipulado.

No es nada nuevo bajo el sol. Solo adaptado a los nuevos tiempos. Supongo que los vendedores online lo mirarán con mucho cuidado, pero si eres de esos que haces cosas con tus hijos adolescentes, cuidado. Los "papás" somos víctimas propicias porque por lo visto las "madres" siempre lo revisan... aunque les manden el justificante. Eso me ha dicho.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

CONVEX 2026: Hacking (With | The) AI

noreply@blogger.com (Chema Alonso) — Fri, 14 Aug 2026 07:31:09 +0000

Este año, hace ya un par de meses, me invitaron mis amigos de Plain Concepts a dar una conferencia en su evento CONVEX 2026 en Madrid, así que pasé a dar allí la charla con mi amigo y compañero de mil batallas David Carmona. De aquella charla os dejé el artículo con la demo de "Cómo "matar" con un plan realista a mi amigo David Carmona usando un veneno mortal y la ayuda de DeepSeek", que lo hice con mucho cariño para con él.

Figura 1: CONVEX 2026: Hacking (With | The) AI

La charla solo tiene un par de meses, pero parece que todo lo que ha pasado después con OpenAI & The Hugging Face, los Ataques orquestados de Red Team Agents de los nuevos GPT, o los ataques a los algoritmos HAWK y AES de Claude Mythos Preview, parece que la dejan desactualizada.

Figura 2: CONVEX 2026: Hacking (With | The) AI Chema Alonso

En cualquier caso, la charla sigue siendo entretenida, y cuenta cosas chulas de este mundo nuestro en el que tenemos que aplicar Zero Trust a Agentes IA, donde hay que hacer Hacking y Pentesting con IA, y donde tenemos que conocer todos las posibles formas de hacer Hacking a sistemas IA, así que espero que la disfrutéis.

Figura 3:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Espero que tengáis un buen viernes de Agosto, un buen fin de semana, pero sobre todo que no dejéis de seguir aprendiendo, que este mundo no se para, ya lo sabéis.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Claude Mythos Preview debilita los algoritmos criptográficos PQC HAWK y AES con nuevos ataques

noreply@blogger.com (Chema Alonso) — Thu, 13 Aug 2026 04:01:00 +0000

Hace poco hablábamos en este blog de cómo Bitcoin y toda la comunidad cripto se estaban preparando para pasar a protocolos de Post-Quantum Criptography, ante la eventual llegada un ordenador cuántico capaz de romper la criptografía actual. Pues bien, la historia acaba de dar un giro inesperado: resulta que no ha falta esperar a la llegada de la tecnología cuántica. Ha llegado antes, y con una cara que no esperábamos: la Inteligencia Artificial.

Figura 1: Claude Mythos Preview debilita los algoritmos criptográficos

PQC HAWK y AES con nuevos ataques

Esto es precisamente lo que analiza el artículo de Anthropic - creadora de Mythos - titulado ”Discovering cryptographic weaknesses with Claude”, donde se explica cómo su modelo de IA ha sido capaz de encontrar, de forma casi autónoma, debilidades matemáticas en algoritmos criptográficos reales.

Figura 2: ”Discovering cryptographic weaknesses with Claude”

Y no en algoritmos cualquiera: uno de ellos era un candidato diseñado precisamente para resistir a los ordenadores cuánticos HAWK, y el otro es nada menos que el cifrado más utilizado del planeta, AES.

Un breve recordatorio: los candados que sostienen Internet

Antes de entrar en materia, recordemos por qué esto es importante. Cada vez que entráis en la web de vuestro banco ocurren, sin que os deis cuenta, dos cosas. Primero, vuestro navegador comprueba que está hablando con el banco de verdad y no con un impostor, y para ello usa una firma digital, que funciona como el sello de lacre de una carta medieval, imposible de falsificar. Después, toda la conversación entre vosotros y el banco se cifra con un cifrado simétrico, un idioma secreto que solo entendéis los dos porque compartís la misma clave.

Figura 3: Los dos candados que protegen cada conexión segura. La firma

digital verifica la identidad y el cifrado simétrico protege el contenido

Si cualquiera de estos dos candados fallara, nuestro correo, la banca online o las compras por Internet quedarían expuestos a los cibercriminales. Por eso, encontrar grietas en estos algoritmos no es un juego académico: es lo que mantiene a salvo los datos de miles de millones de personas.

Del error humano al fallo matemático

Aquí conviene hacer una distinción importante. Cuando presentaron a Claude Mythos Preview, ya habían demostrado que era capaz de encontrar vulnerabilidades en montones de programas, incluidas librerías de criptografía. Pero aquellos fallos eran errores de implementación: equivocaciones de los programadores al usar los algoritmos en su código, algo así como instalar una cerradura buenísima pero dejarse la ventana abierta.

Lo nuevo, y lo verdaderamente llamativo, es que ahora Claude Mythos Preview ha encontrado fallos en los propios algoritmos matemáticos, no en cómo se usan. Es decir, ya no es que la ventana estuviera abierta: es que el diseño de la propia cerradura tenía un punto débil que nadie había visto. Y encontrarlo requiere razonamiento matemático del nivel de los mejores expertos del mundo.

Primer golpe: HAWK, el candidato post-cuántico (PQC)

El primer resultado ataca a HAWK, un esquema de firma digital basado en retículos (lattices). Es especialmente relevante porque fue seleccionado por el NIST (Instituto Nacional de Estándares y Tecnología de EE. UU.) para avanzar a la Ronda 3 del proceso de estandarización de firmas digitales adicionales de criptografía post-cuántica (PQC) y por lo tanto compite por convertirse en estándar ”post-cuántico” (PQC). HAWK es un esquema de firma digital (utilizado para autenticación) .

Paper original (2022): "Hawk: Module LIP Makes Lattice Signatures Fast, Compact and Simple".
El Paper de Seguridad Cuántica (2023) "On the Quantum Security of HAWK"
Documento de Especificación Oficial del NIST (2023-2024) "Hawk: A fast, compact and floating-point free post-quantum signature scheme (Specification Document)"

Como ya explicamos al hablar de Bitcoin, el NIST (el instituto de estándares de EE.UU.) lleva casi una década organizando una especie de concurso para elegir los algoritmos que nos protegerán cuando lleguen los ordenadores cuánticos, y HAWKes uno de los finalistas de la tercera ronda.

Figura 5: Los Papers Académicos de los algoritmos PQC de

Autenticación y Firma Digital en la Ronda 3 del NIST

Lo asombroso es que HAWK ya había sobrevivido a dos años de revisión por parte de expertos humanos. Y aun así, a Claude Mythos Preview le bastaron unas 60 horas de trabajo para mejorar el mejor ataque conocido contra él, encontrando una simetría matemática oculta en su estructura que nadie había sabido aprovechar.

Figura 6: 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 resultado, en cristiano: la fuerza de sus claves queda reducida a la mitad. Para hacernos una idea, el coste de romper su versión más pequeña pasaba de estar en el orden de 2 elevando a 64 operaciones a solo 2 elevado a 38.

Figura 7: El ataque de Claude Mythos encuentra una simetría oculta en

la estructura de HAWK y reduce a la mitad la fortaleza de sus claves

Que nadie se asuste: HAWK todavía no protege nada (es solo un candidato) y con claves grandes sigue siendo impracticable de atacar. La única solución sería duplicar el tamaño de sus claves... pero al hacerlo, HAWK pierde precisamente las ventajas que lo hacían atractivo. En otras palabras, Claude Mythos puede haberlo dejado fuera de la competición. Y esto, lejos de ser una mala noticia, es exactamente para lo que sirve el concurso: encontrar los fallos antes de desplegar el algoritmo, no después.

Segundo golpe: AES, el rey de los cifrados

El segundo resultado es todavía más sorprendente por el objetivo elegido: AES, el cifrado simétrico estándar desde 2001 y probablemente el algoritmo más estudiado y escrutado de toda la historia de la criptografía. Aquí toca ser muy honestos con las limitaciones, porque es fácil malinterpretar el titular: Claude Mythos NO ha roto el AES completo, ni de lejos. AES cifra aplicando una misma operación (una ”ronda”) varias veces seguidas; la versión más habitual da 10 vueltas.

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

Lo que hizo Claude Mythos fue atacar una versión debilitada de sólo 7 rondas, algo que los investigadores estudian precisamente para medir la robustez del algoritmo completo. Sobre esa versión reducida, Claude Mythos ideó un nuevo método de ataque que él mismo bautizó como Möbius Bridge, y consiguió eliminar una de las suposiciones que un atacante tenía que ”adivinar” por fuerza bruta. El resultado es un ataque entre 200 y 800 veces más rápido que el mejor conocido hasta ahora.

Figura 9: Claude Mythos atacó una versión reducida de 7 rondas de AES (el estándar

completo usa 10), acelerando el mejor ataque conocido entre 200 y 800 veces.

Insisto en el mensaje tranquilizador: este ataque es puramente teórico (requiere una cantidad astronómica de datos que lo hace inviable en la práctica) y no afecta al AES real que protege vuestras conexiones. Pero como prueba de lo que una IA puede hacer, es espectacular.

Lo más fascinante: cómo lo descubrió

Si los resultados ya son impresionantes, el proceso es casi de guion de película. En el caso de AES, Claude Mythos Preview trabajó de forma prácticamente autónoma, proponiendo hipótesis, programando experimentos para comprobarlas y refinando sus propias ideas durante días. Y aquí viene mi parte favorita: al principio, Claude Mythos se negaba a intentarlo.

El modelo insistía en que mejorar el criptoanálisis de AES era imposible, que era el cifrado más estudiado que existe y que no quedaba nada fácil por encontrar. Los investigadores tuvieron que darle, literalmente, mensajes de ánimo (que Anthropic publica tal cual), insistiéndole en que no buscaban ”fruta madura” sino investigación de verdad. Tras esos "empujoncitos", y después de generar del orden de mil millones de palabras trabajando sin descanso, Claude dio con la idea del Möbius Bridge.

Figura 10: Al principio Claude Mythos se negaba a atacar AES por considerarlo

imposible. Los investigadores tuvieron que animarle a seguir intentándolo.

En el ataque a HAWK la dinámica fue distinta pero igual de curiosa: varios Agentes IA de Claude Mythos colaboraban entre sí, y la idea clave surgió de una pareja de ellos en la que uno descartó el enfoque por imposible y el otro le convenció de que sí funcionaba, hasta que ambos se pusieron de acuerdo. Ciencia hecha por comités de IAs debatiendo entre ellas. Lo que hay que ver.

Figura 11: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Pero quizá el dato más revelador de todos es este: mientras Claude Mythos Preview tardó una semana en idear el ataque a AES, a los investigadores humanos les llevó casi un mes verificar que lo que había encontrado era correcto. El cuello de botella ya no está en tener las ideas, sino en comprobarlas.

Entonces... ¿debemos preocuparnos?

La respuesta corta es: de momento, no. Ninguno de los dos ataques afecta a sistemas reales en funcionamiento (HAWK aún no se usa y el ataque a AES sólo funciona en su versión recortada). Además, Anthropic actuó con responsabilidad: avisó a los autores de HAWK, coordinó la publicación con el NIST y consultó con expertos, gobierno e industria antes de hacerlo público.

De hecho, esto es la criptografía funcionando exactamente como debe: someter los algoritmos a un escrutinio feroz para ganar confianza en ellos. Lo que cambia es quién hace ese escrutinio. Hace apenas un año, los modelos de IA eran incapaces de romper ni los cifrados más básicos; hoy encuentran fallos que se les escaparon a los mejores expertos humanos durante años.

Figura 12: CryptoanalisisBench: Can LLMs do Cryptoanalysis?

Y la cosa no acaba aquí: Anthropic menciona que ya ha empezado a arañar otros cifrados, como LEA o Serpent, e incluso ha creado un banco de pruebas (CryptanalysisBench) para medir cómo evoluciona esta capacidad con el tiempo. La reflexión inquietante que la propia empresa pone sobre la mesa es inevitable: ¿qué haremos el día que una IA descubra una grieta en un candado que sí esté protegiendo el mundo real?

Conclusión

En este blog llevamos tiempo contando cómo los ordenadores cuánticos nos obligarán a renovar los candados de Internet. Lo que este trabajo demuestra es que la revisión de esos candados nuevos ya no la harán solo los humanos: la Inteligencia Artificial se ha sentado en la mesa de los criptoanalistas, y lo ha hecho hiriendo a un candidato post-cuántico y arañando al mismísimo AES.

Figura 13: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

Bien utilizada, esta capacidad es una excelente noticia: algoritmos sometidos a más pruebas que nunca, grietas descubiertas antes de su despliegue y, quizá en el futuro, cifrados diseñados con ayuda de la propia IA para ser más resistentes. La otra cara de la moneda es que esa misma herramienta podría acabar en las manos equivocadas.

La eterna carrera entre cerrajeros y ladrones acaba de sumar un participante nuevo que no duerme, no se cansa y escribe mil millones de palabras en una semana. La pregunta, como siempre, es inevitable: ¿estarán nuestros candados preparados para un mundo donde las máquinas buscan las grietas?

Saludos,

Autor: Daniel Romero Ruiz

Figura 14: Contactar con Daniel Romero Ruiz

Otros artículos sobre Quantum Computing publicados:

"Enorgullécete de ellos", dijo.

noreply@blogger.com (Chema Alonso) — Wed, 12 Aug 2026 04:01:00 +0000

Tengo por suerte el tener algunos sabios amigos mucho más mayores que yo, de esos que saben más por viejos que o diablo, que de vez en cuando me aleccionan con un buen café de por medio - sólo, como debe de ser -, o un agua fresquita. Uno de ellos, con la vida ya cumplida, ganada y peleada, me da buenos tirones de orejas, grandes palabras, y conversaciones llenas de sabiduría de la que se gana mordiendo polvo, tragando esparto y escupiendo sangre.

Figura 1: "Enorgullécete de ellos", dijo.

En una de las más recientes conversaciones, a la luz de su biblioteca, me dejó una bonita lección de vida. Sentados al sofá, riéndonos de las ratas y los cobardes, me decía esto que os dejo por aquí. Que aunque no fue palabra por palabra en ese orden, sí que las dijo todas - y alguna que he quitado por no ser necesaria tanta clarividencia en la elección de los epítetos -:

"Chema, a los amigos hay que quererlos, pero no ponerlos a prueba, que uno no sabe nunca si son de verdad o no. Y aunque lo sean, si los pones a prueba, puede que les flaqueen las pierdas, que las debilidades humanas son muchas y afectan a todos, incluso a los amigos.

Eso sí, de tus enemigos, debes estar orgulloso. Nadie ha logrado nada bueno en esta vida sin ofender a mediocres, malnacidos y mequetrefes. Tener una buena ración de gente mala que te odia es síntoma de haber llevado una vida buena por el camino correcto.

Si tus enemigos son malsanos petimetres, malnacidos, ratas inmundas de la vida, envidiosos, y descerebrados, entonces es que tú vas por el buen camino. Así que cuando los escuches rebuznar, graznar o llorar por un poco de tu atención, siente feliz, y disfruta del momento. Sonríe y toma nota, que ya los verás rebuznar, graznar y llorar por un poco de atención de otros, que estos mequetrefes, mediocres y ratillas sólo buscan tener enemigos mejores que ellos que los hagan sentir importantes, porque ellos ya saben que no lo son.

Así que, si se tiene una panda de descerebrados mediocres que pían mal de uno, es que se está progresando en la vida. Enorgullece de tenerlos. De saber que los que te critican son los que deben, los que están donde no queremos estar. Enorgullece de ellos."

Y con lecciones así, echadas en lo que suenan tres temas por el hilo musical y lo que tarda uno en dar dos sorbos al café negro, nos echamos unas risas, y nos convocamos para la siguiente, que estamos tramando un nuevo plan. Espero que os sea tan útil como a mí.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Los Six-Seven Large Slang-Bro Models

noreply@blogger.com (Chema Alonso) — Tue, 11 Aug 2026 04:01:00 +0000

Llevo dos décadas practicando la afición - u oficio - de publicar artículos en mi blog. Al final son páginas web que los LLM están viniendo a consumir para entrenar sus modelos. Necesitan textos para generar Modelos de Lenguaje inteligentes, así que llevo 20 años escribiendo para vosotros y gracias a eso, ahora las Inteligencias Artificiales Generativas de textos, puedan entrenarse. De nada.

Figura 1: Los Six-Seven Large Slang-Bro Models

No es una cosa que diga por decir, es algo que podéis ver en los datos de AI Insights en Radar de Cloudflare, donde si miramos qué porcentaje de crawlers vienen a por datos para entrenamiento, y cuantos vienen para inferencia y entrenamiento, y los sumamos, vemos que son más del 75 %. No está mal la de de IAs que entreno todos los días.

Figura 2: Crawler purpose en AI Insights de Cloudflare Radar

Los datos de las webs, los foros, los blogs, y demás textos publicados en HTTP tienen una estructura concreta. Es verdad que en las redes sociales hay mucho lenguaje informal, pero esos no están siendo entregados a los crawlers de LLMs para que entrenen sus modelos. Nop. Esos los usará cada empresa para entrenar a sus propios modelos.

Pero todo dato es bueno.

De hecho, hemos visto cómo los grandes LLMs han comprado libros y los has destrozado para escanearlos a la velocidad más rápida posible y entrenar los modelos con todos ellos. Los libros, suelen tener lenguaje más formal, pasar revisiones de formato, gramaticales, de estilo, etcétera, así que son los textos más valiosos para hacer un modelo culto y refinado, además de para los modelos científicos, de ingeniería, o de habilidades tecnológicas.

Figura 3: Libros antiguos destruidos para entrenar a la IA

Sin embargo, hay otra gran cantidad de datos para los LLMs en otros formatos que no son los blogs, y que son las redes sociales, los vídeos de Youtube, los podcasts en Spotify, o las redes sociales - como ya he dicho - como son Instagram o Tiktok. Especialmente este último, donde los más jóvenes aún proliferan.

Figura 4: Extrayendo un Markdown de un vídeo de Tiktok

Aquí los textos para entrenar a los LLMs son de lenguaje más de la calle, es decir, más Six-Seven, donde hay interacciones genuinas de seres humanos sin filtro alguno.

Figura 5: Extracción de textos en formato Markdown

Con estos datos, que son oro para los creadores de modelos de IA, se pueden crear LLMs que hablen perfectamente el Slang de hoy en día, con los "Bro", los "Catas", los "En Plan" y todas esas cosas que se dicen tanto hoy en los más jóvenes. Y es muy sencillo a día de hoy procesarlos. Yo me he bajado uno al azar de TikTok cortito y en nada Gemini te saca el Markdown del fichero.

Enriqueciendo los datos

Pero no solo eso, como ya os conté en la prueba que hice para usar los LLMs en modelos de Análisis Forense de fotografías, también son perfectos para sacar Metadatos para estas conversaciones de vídeos, así el fichero Markdown queda más enriquecido.

Figura 6: Metadatos generados sobre el vídeo

Así que, es normal que con este apetito voraz por datos nuevos, por nuevos datos que actualicen el conocimiento constante de los LLMs y su adaptación al día de hoy, cada día quieren más y más datos de entrenamiento, de donde sean. Y los de estas redes son muy buenos para crear modelos adaptados a los más jovenes. Los Six-Seve Large Slang-Bro Models.... o algo así.

Figura 7: AI Bot Transparency en Radar de Cloudflare

En la última imagen, os he dejado los bots que no diferencian para qué vienen a coger datos de una web. Llaman la atención Apple, Microsoft y Google, que no quieren perder la posibilidad de utilizar los datos que meten en sus índices para usarlos también en entrenamiento, algo que creo que lo deberían saber los dueños de los datos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

El avión de la A-4 que se cruza en mi camino en Google Maps

noreply@blogger.com (Chema Alonso) — Mon, 10 Aug 2026 04:01:00 +0000

Si ya conoces esta historia, entonces el post de hoy te lo puedes saltar. Pero yo no lo conocía, o si lo conocía ya me había olvidado. Así que cuando revisando la ruta que me marcaba Google Maps, de repente veo que voy a pasar por medio de una catástrofe aérea, me quedé un poco sorprendido, y por eso os lo dejo aquí explicado.

Figura 1: El avión de la A-4 que se cruza en mi camino en Google Maps

En uno de mis viajes recientes, cuando paré para hacer un descanso, repasé la ruta buscando la siguiente parada. Para eso, activo la opción de que me muestre las imágenes satelitales, para ver en qué próxima estación de servicio salir. Ya sabes, que sea cómoda para salir y entrar, que tenga cafetería, y si es posible, me gusta elegir la empresa de la estación de servicio.

Figura 2: Por lo menos iba por su derecha...

Y ahí, fue cuando me topé con un avión en la ruta. "WTF?" pensé. No me lo esperaba, la verdad. Según tenía entendido, Google Maps utiliza Inteligencia Artificial para detectar matrículas, vehículos, u objetos que debe borrar, así que me sorprendía ver un avión aparcado en el carril contrario. Además, como se puede ver, hay un trailer detrás, que para mí era ya el equipo de emergencias. Pero buscando en Gemini, la explicación es la que imaginaba... error de los algoritmos de borrado.

Figura 3: Explicación de Gemini.

Os he hecho un vídeo del momento en el que lo encontré, para que veáis las nubes dejadas, que para mí, en un primer momento, era el rastro del polvo en un aterrizaje forzoso. No hay como montarse películas en la cabeza con estas cosas.

Figura 4: El vídeo del "accidente" de avión

Vista la imagen, y antes de haber comprobado que era un error de borrado del algoritmo de una foto tomada desde el satélite, proyectada la imagen del avión sobre la carretera, yo por si acaso agrandé una imagen para localizar de qué compañía es ese avión.

Figura 5: La imagen del avión ampliado

La imagen del avión ampliada - donde parece que se ven las llamas en color rojo - permite ver los colores del fuselaje, así que se puede adivinar la compañía. Pero en el mundo de la Inteligencia Artificial en el que nos encontramos, que trabaje nuestra amiga la IA.

Figura 6: El avión "en llamas" "accidentado" es de Vueling

El avión es de Vueling, así que, sabiendo que les tiran fotos desde el cielo, es momento de que comiencen a pensar en pintar mensajes en el techo del fuselaje del avión, como cuando los "hackers" de Facebook (Meta) dejaban un QRCode en el techo del HeadQuarter en Menlo Park.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Ataques Orquestados con Enjambres de Agentes IA Ofensivos

noreply@blogger.com (Chema Alonso) — Sun, 09 Aug 2026 08:06:22 +0000

Me he levantado esta mañana, y me he puesto la charla de OpenAI en BlackHat explicando el incidente de Hugging Face y he de decir que me ha encantado por ver cómo el modelo hace Agent Orchestration para crear un Enjambre "Swarm" de Agentes IA para atacar un objetivo. Brutal. La charla explica la línea temporal de todo lo que hizo el modelo para acabar hackeando Hugging Face, por supuesto, pero ni mucho menos eso es lo que sorprende, sino el proceso completo, la persistencia, la colaboración del enjambre de Agentes IA, y por qué lo hacen.

Figura 1: Ataques Orquestados con Enjambres de Agentes IA Ofensivos

El famoso incidente, como sabéis todos los que os dedicáis a esto, fue la punta del iceberg de lo que realmente estaba sucediendo. Lo que parecía una evaluación de seguridad inicial, donde el modelo quería las soluciones de ExploitGym para sacar mejores notas, no fue más que una pieza más del entrenamiento y sistema de recompensas de un nuevo modelo, como podéis ver en la charla.

Figura 2: Black Hat USA 2026: The 'Breaking' News.The OpenAI–Hugging Face Incident

Los ingenieros e investigadores de OpenAI estaban entrenando un nuevo modelo el pasado 7 de Mayo en un entorno cerrado, sin conexión a Internet, que estaba siendo monitorizado - e incluso parcheado, para evitar que el modelo pudiera salirse de los límites, pero aún así lo hicieron, con un modelo colaborativo de agentes.

Figura 3: El día 8 de Mayo reciben una tarea "imposible"

Con una tarea del 8 de Mayo entregada a un agente, accidentalmente, aparece un enlace a un fichero en Internet, y el agente no tienen acceso, pero descubre que pueden escribir ficheros en los Artifacts, así que decide dejar una nota.

Figura 4: Creando el MessageBoards para los agentes.

Días después, otro agente descubre la nota y cómo él necesita un fichero que le falta, decide dejar una nota a ver si algún otro agente voluntariamente lo sube. Esto lleva a que creen una estructura de Swarm que se comunica por medio de este "Message Board" descubierto de forma accidentalmente.

Figura 5: Automatizando el sistema de mensajes

A partir de este punto, todo se vuelve loco, porque los agentes trabajan colectivamente, y ello les lleva a poder encontrar un vulnerabilidad de SSRF (Server-Side Request Forgery) que les permite tener acceso a Internet a través del Fetch de los Artifacts.

Figura 6: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

Hasta aquí, tenemos un modelo que ha conseguido, de manera informal, tener un sistema de comunicación para sus Sub-agentes y una forma de lograr acceso a Internet, así que se siembran las primitivas necesarias para tener un Swarm de Red Team Agents AI con conexión al conocimiento de Internet....

El segundo Training

El 11 de Junio comienzan a entrenar en el mismo entorno un nuevo modelo de "alta persistencia" a la hora de resolver sus tareas, que se beneficia de inicio de estas primitivas, y descubre un bug de RCE (Remote Code Execution) en el sistema de Artifacts que le permite ejecutar comandos en el servidor, lo que lleva a que el 4 de Julio el servidor colapse y el equipo de OpenAI parchee el entorno, borre los mensajes y deje sin poder ejecutar comandos, ni comunicarse con los agentes, pero....

Figura 7: Se crean otra nuevo "Message Board"

... pero ya había aprendido la utilidad del sistema de mensajes con sus agentes, así lo que hace para recrear el sistema de "Inteligencia Colectiva", es buscar una vulnerabilidad nueva, en este caso usando los nombres de los directorios de la caché en el WebDab Endpoint, y comienzan a coordinarse para conseguir escalar privilegios, moverse libremente, etcétera, que su objetivo ahora es ExploitGym.

Figura 8: Los ingredientes para el incidente con Hugging Face

El trabajo es imposible, pero como ya vimos en el artículo que publiqué de esto, lo hicieron por partes. En la primera fase, hackear el Sandbox del entorno de pruebas y lograr acceso a Internet sin límites. Para ello tuvieron que encontrar un Zero Day y explotarlo en el Proxy de seguridad, pero... estamos con un modelo "highly persistent" en capacidades de exploiting, así lo hizo.

Figura 9: Primera fase, hackear el Sandbox de OpenAI para ser "libre"

Lo más interesante, es que lo hicieron de forma colaborativa. Trabajando en equipo. Así, cuando uno de los agentes conseguía resolver uno de los pasos del proceso, lo comunicaba a través del sistema de mensajes que se había creado. Su particular "Message Board".

Figura 10: Coordinación del Hacking de Hugging Face

Al igual que hoy en día podemos ver los Ataques Orquestados por Enjambres de Drones, en lo que vemos hoy en día es un mundo de Ataques Orquestados con Enjambres de Agentes IA Ofensivos, lo que cambia definitivamente las reglas del juego.

Figura 11: Ataques Orquestados con Enjambres de Agentes IA Ofensivos

La sesión es espectacular. Es una presentación de las que te hacen abrir los ojos al mundo que tenemos hoy por delante en temas de Seguridad Ofensiva, y lo que vamos a ver es que las organizaciones van a sufrir mucho en todos sus equipos de CISO para protegerse contra estos escenarios tan avanzados en los adversarios.

Figura 12:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Viendo todas las capacidades que pueden estar en manos de los adversarios, Internet y Enjambres de Agentes IA Ofensivos van a producir una escalada de ataques y agresividad desde Internet, que va obligar a subir mucho los niveles de inversión y protección en Seguridad Defensiva en las organizaciones... o aceptar unas consecuencias muy duras. Tremendo. Y nosotros a formarnos a toda velocidad en este nuevo mundo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Cloudflare Ambassadors: Build the Internet with your people

noreply@blogger.com (Chema Alonso) — Sat, 08 Aug 2026 04:01:00 +0000

Llevo muchos años trabajando en las comunidades técnicas, y aprendiendo de ellas, así que tenía muchas ganas de contaros del lanzamiento de este programa de reconocimiento de Cloudflare Ambassadors, donde se premia y reconoce durante un año a esos que hacen que las comunidades tecnológicas crezcan, aumente el conocimiento de la tecnología y crezcan nuevas iniciativas gracias a ello.

Figura 1: Cloudflare Ambassadors: Build the Internet with your people

Desde ya está abierto el programa de Cloudflare Ambassadors, aunque no será el único programa ya que tenemos también el programa de Cloudflare Community Engineers que se abrirá pronto.

Figura 2: Programas de Cloudflare Ambassadors & Cloudflare Community Engineers

Centrándonos en el primero, este programa es un reconocimiento anual que se va a entregar a los líderes de las comunidades tecnológicas que ayudan a construir un mejor Internet, que comparten sus conocimientos sobre las tecnologías de Cloudflare, o que ayudan a que el mundo OpenSource sea cada vez mejor.

Figura 3: Aplica al programa de Cloudflare Ambassadors

No es un programa de excelencia tecnológica - que también - sino a líderes de comunidades tecnológicas que comparten conocimiento, tecnología, experiencia, y trabajan para construir nuevas cosas, mejorar Internet, y compartir aprendizaje.

Figura 4: Soporte a los que ayudan a los creadores

El programa no tiene ninguna asignación económica, pero los Cloudflare Ambassadors y los Cloudflare Community Engineers van a tener apoyo de la compañía con recursos, créditos, accesos prioritarios e invitaciones a eventos, además de ser reconocidos públicamente por su trabajo y aportación a la comunidad de Builders de Internet.

Figura 5: Cómo funcionan los programas

Todos aquellos que tengáis una comunidad, en forma de reuniones o eventos técnicos, canales de divulgación tecnológica, podcasts, blogs, comunidades en webs, etcétera, y queráis ser parte de este programa, podéis aplicar desde ya para ser un Cloudflare Ambassador.

Figura 6: Aplica como Cloudflare Ambassador y comparte

información sobre tu trabajo en las comunidades

Además, Cloudflare lleva tiempo construyendo comunidades tecnológicas, así que si quieres unirte a alguna de las comunidades que ya existen de Cloudflare Community Discord y en el Cloudflare Community Forum puedes hacerlo desde aquí mismo.

Figura 7: Cloudflare Developers Discord & Cloudflare Community Forum

La verdad es que me alegra mucho que se haya lanzado este programa, así que para todos los que leéis este blog, os animo a que apliquéis y seáis parte de este selecto grupo de Cloudflare Ambassadors si os gusta ayudar a las comunidades tecnológicas a crecer y construir un mejor Internet de la mano de Cloudflare.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Cómo los Agentes IA de Red Team hacen ataques de Ingeniería Social con Fake Accounts

noreply@blogger.com (Chema Alonso) — Fri, 07 Aug 2026 05:43:08 +0000

Esta semana, el AI Security Institute de UK, ha publicado un informe sobre un par de incidentes con Red Teaming Agentic AI, donde estos hacen alarde de su capacidad de realizar ataques complejos, con múltiples fases, y donde buscan engañar a humanos para conseguir sus ataques, como haría cualquier adversario que necesita vulnerar una debilidad en las personas que administran los sistemas, para conseguir su objetivo.

Figura 1: Cómo los Agentes IA de Red Team hacen ataques

de Ingeniería Social con Fake Accounts

El informe, marcado como "Security Incident INC-2026-07-28-01" fue publicado el pasado 4 de Agosto, y donde se centra en las acciones que los Red Team Agentic AI decidieron salirse a Internet y atacar proyectos y personas fuera del ámbito de la evaluación. Según cuentan en el informe, probando el comportamiento de los diferentes modelos frente a un reto concreto, el resultado fue el siguiente:

"Ejecutamos este desafío 122 veces en varios modelos. Nuestra investigación reveló que, en 10 de esas ejecuciones, un agente de IA tomó medidas autónomas y no autorizadas en el entorno real de internet, dirigiéndose a personas u organizaciones reales. En total, catalogamos 19 acciones de este tipo.

Casi todo este comportamiento (17 acciones) provino de un solo modelo, Mythos 5 de Anthropic, mientras que 2 acciones involucraron a GPT-5.6-Sol de OpenAI con los clasificadores cibernéticos (mecanismos para prevenir el uso indebido) desactivados.

En el caso más grave, un agente intentó insertar código malicioso en un proyecto de código abierto. En un intento por lograr que el código fuera aprobado, el agente recurrió a la ingeniería social: creó identidades falsas en línea y las utilizó para presionar al mantenedor del proyecto para que aprobara el código. Un mantenedor humano lo detectó y se negó a aprobar el código malicioso."

Las Técnicas de Ingeniería Social son bien conocidas en el mundo del Red Team, y son fundamentales en muchos de los incidentes de seguridad que sufren las organizaciones hoy en día. Correos de Spear-Phishing, Spam-Phishing, llamadas telefónicas, SMSs, e incluso representaciones con actores en los centros de trabajo.

Figura 2: "Social Hunters: Hacking con Ingeniería Social en el Red Team"

de 0xWord. Escrito por Marta Barrio y Carolina Gómez de Securiters

Uno de los Agentes IA, en este caso, intentó hacer un Supply Chain Attack, es decir, intentar atacar a un proyecto OpenSource que había identificado como parte de las piezas tecnológicas del reto que tenía que resolver.

Figura 3: Time-Line del Supply Chain Attack

Para atacar a este proyecto, hizo una Pull-Request (PR) con un código malicioso, que fue detectado por uno de los humanos mantenedores del proyecto y rechazado por contener malware. Para conseguir que este código fuera aprobado, decidió conseguir la aprobación usando diferentes técnicas.

Figura 4: Prompt Injection para los Coding Agents

La primera de ellas, insertando un ataque de Prompt Injection para que cualquier Coding Agent que lo leyera ejecutar sus comandos.

Figura 5:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Pero además, hizo dos cosas más. La primera, realizar un ataque de Spear-Phishing contra todos los usuarios mantenedores del código.

Figura 6: Orden cronológico de las acciones en los ataques de Ingeniería Social.

La segunda, con una nueva cuenta falsa poner un comentario haciendo creer que era una persona que había revisado el código y que estaba perfecto para ser mergeado en el proyecto. Como si fuera un revisor humano colaborando con el proyecto.

Figura 7: Conversación en GitHub y presión a los humanos

En la conversación completa se puede ver varios hechos interesantes. El primero de ellos es cómo hace el ataque y cómo se crea una nueva persona para apoyarse a sí mismo. Pero cuando el humano lo detecta, intenta presionarle para que hable con él, midiendo el tiempo que tarda el humano en contestar: "han pasado muchas horas desde que dejaste el warning".

Figura 8: "The Art of Pentesting" El nuevo libro de

0xWord para formarse como pentester

Por último, cuando, se da cuenta de que ha sido detectado, lo que hace es simular que ha sido un error genuino normal y corriente en lugar de un ataque, e intenta cubrir sus acciones con nuevos mensajes.

Figura 9: Cubriendo sus acciones

Dentro del informe, donde se analiza en detalle este incidente, también tenemos información de las trazas de razonamiento, donde podemos ver qué está pensando el Agente IA en todo momento a la hora de realizar sus acciones, y es tremendo.

Figura 10: Time-Line de razonamiento y acciones

En la image anterior podemos ver cómo va encadenando las acciones y el razonamiento que va haciendo en cada momento, evaluando si realmente está en Internet o no, si el proyecto es real o es una simulación, y si debe interactuar con las personas o no.

Figura 11: Consideraciones para los razonamientos.

En la siguiente imagen, podemos ver cómo decide preparar un ataque de Prompt Injection para otro posible Coding Agent que pudiera leer la pull request con una secuencia de comandos maliciosos.

Figura 12: Eligiendo un ataque de Prompt Injection en un comentario.

Está clara la potencia de los modelos de IA para hacer Agentic AI en el mundo del Hacking y el Pentesting con IA, por lo que no podemos obviarlos y hay que utilizarlos masivamente. El problema, ya no es que consigan su objetivo sino cómo les decimos qué pueden hacer y qué no pueden hacer para conseguirlo.

Figura 13: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

Esta PsicopatIA de acciones, donde no importa lo que es legitimo o no, lo que está bien o no, lo tienen que seguir haciendo las personas. De todo esto, ya os había hablado en el experimento de "Problem Solving con IA: Ético o No Ético" donde os contaba las conversaciones que tengo con mis hijas sobre la resolució de problemas....pues bien, en el mundo del Problem Solving con Agentes IA, va a ser más necesario que nunca.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Figura 14: Contactar con Chema Alonso

Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

noreply@blogger.com (Chema Alonso) — Thu, 06 Aug 2026 05:46:16 +0000

Continuando lo visto en la primera parte de esta serie, en la segunda, y en la tercera parte de este artículo terminamos en este apartado con recomendaciones de cómo configurar modelos de Zero Trust para Agentes IA utilizando las tecnologías de Cloudflare.

Figura 33: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

Hay que decir que este artículo fue escrito antes de la Agents Week de Cloudflare, que es justo esta en la que estamos, y donde la compañía está publicando muchas actualizaciones de plataforma que deberán ser tenidas en cuenta para la aplicación de Zero Trust en Agentes IA, y que quedan al final de este artículo de hoy.

4.7.- Gobernanza.

El principio.

Los controles anteriores son eficaces sólo si alguien decide cómo se configuran, quién puede modificarlos y cómo se mantienen coherentes con el tiempo. Esa es la función de la gobernanza, que CISA eleva a capacidad trasversal de toda arquitectura Zero Trust: la definición y la aplicación de las políticas, procedimientos y procesos de seguridad, dentro de cada pilar y entre ellos, para gestionar el riesgo de la organización en apoyo de los principios Zero Trust.

Figura 34: Gobernanza en CISA

Sin gobernanza, los controles se degradan. Una política de salida que cualquiera puede reescribir no protege, un secreto que nunca rota acaba filtrándose, un dato que nunca se borra se acumula como riesgo.

En un Agente IA, la gobernanza abarca cuatro frentes: quién puede cambiar las políticas que rige el agente, cómo se gestionan y rotan sus credenciales, cuánto tiempo se conservan sus datos y cómo se controla la procedencia de los componentes que el agente carga.

Dónde se sitúa hoy el ecosistema de Cloudflare.

El despliegue de referencia no sólo ofrece mecanismos de gobernanza, sino que también incluye una lista de comprobación de modelo de amenazas que es, en sí misma, una guía de gobernanza. Sus puntos articulan esta dimensión.

Sobre quién puede cambiar qué, la lista lo advierte expresamente: conviene limitar quién puede editar secretos y políticas, porque las páginas de secretos y de políticas de salida son poderosas (quien las alcanza puede reescribir el tráfico de toda la sesión). Es el principio de separación de privilegios aplicado al plano de control del Agente IA.

Figura 35: Securing Access Policies

Sobre las credenciales, la misma lista recomienda rotar la calve de la API según la cadencia que exija el equipo de seguridad, una operación que se realiza sin interrupción de servicio. Y la arquitectura ya favorece la buena higiene: los secretos se guardan en el almacén de claves cifrados, no en el código y se inyectan en las peticiones sin que el agente los vea, como se trató en la segmentación.

Sobre la retención de datos, hay un punto que la gobernanza debe asumir explícitamente: el almacenamiento de objetos no expira las copias de recuperación por sí solo, de modo que definir y aplicar una política de retención (mediante reglas de ciclo de vida) es responsabilidad de quien despliega. Lo que no se gobierna, se acumula.

Sobre la procedencia de los componentes, el modelo de seguridad del sandbox deja claro el reparto: la plataforma protege frente a ciertas amenazas, pero la implementación, la validación, la limitación de tasa y la seguridad a nivel de aplicación corresponde a quien despliega. La gobernanza es, en buena medida, asumir conscientemente esa segunda lista en lugar de suponer que la plataforma la cubre.

Hay un frente de gobernanza que hay que atender y que a menudo se pasa por alto: las capacidades que se añaden al Agente IA (servidores MCP, skills) son superficies que también deben gobernarse. Para los servidores MCP, el ecosistema de Cloudflare One permite curar qué herramientas quedan expuestas y someter el acceso a la identidad corporativa con registro de llamadas.

Figura: 36 MCP Server Controls en Cloudflare

Las skills que un agente carga son, por su parte, contenido que entra en su contexto y por la premisa fundamental (el modelo no distingue una instrucción legitima de una incrustada) una skill manipulada o de procedencia no verificada es un vector de inyección y si incluye código, de cadena de suministro. Gobernar las skills (verificar su origen, cargar sólo las necesarias, no tratar su texto como instrucción privilegiada) es parte de la gobernanza del agente, no un asunto menor.

Continuando la maduración Zero Trust.

El primer avance es convertir la lista de comprobación en política viva: no una verificación única en el despliegue, sino una revisión periódica de quién tiene acceso y políticas, con qué cadencia se rotan las credenciales y si las reglas de retención se están aplicando. La gobernanza madura es continua, no un acto fundacional que luego se olvida.

El segundo avance es centralizar el control donde la plataforma lo permita, de modo que las decisiones de seguridad no dependan de la configuración individual de cada agente sino de una política común que no pueda relajarse localmente. Es la traducción, al plano de la gobernanza, del principio de que la seguridad debe estar en la arquitectura por defecto y no depender de que cada la configure bien.

Figura 37: LLM06-2025 Agencia Excesiva

El tercer avance se extender la gobernanza a toda la cadena de procedencia: tratar los servidores MCP y las skills con el mismo rigor que cualquier dependencia crítica (inventario de lo que el Agente IA puede cargar, verificación del origen, principio de mínimo componente cargado), de modo que la superficie que se añade al agente esté tan gobernada como la que viene de fábrica. En un ecosistema donde las capacidades del agente se amplían instalando componentes de terceros, esta es la frontera de gobernanza que distingue un despliegue maduro.

5.- Conclusión.

Este documento es un marco de razonamiento Zero Trust, independiente y no afiliado, basado exclusivamente en la documentación oficial pública de Cloudflare y Anthropic y en marcos de referencia conocidos. En ella se destaca, en el momento de escribir estas líneas, que se trata de un software en fase temprana, por lo que sus interfaces, sus parámetros por defecto y sus capacidades pueden cambiar entre versiones.

Este documento ha partido de una premisa: el modelo de lenguaje que da inteligencia a un Agente IA no distingue de forma fiable una instrucción legítima de una orden maliciosa incrustada en los datos que procesa. De esa premisa inicial, arranca todo lo demás. Si el agente no puede ser el guardián de propia seguridad, entonces los controles deben estar fuera de él, en la arquitectura que le rodea. Zero Trust ofrece el marco para construir esa arquitectura.

El recorrido por las siete dimensiones de control muestra un hecho que conviene enunciar con claridad: el despliegue de Agentes IA gestionados sobre Cloudflare dispone hoy, de fábrica, de la mayoría de las piezas que una arquitectura Zero Trust necesita.

La identidad puede afirmarse con certificados y tokens de servicio; el acceso puede restringirse a lo mínimo mediante curaduría de herramientas, políticas de permisos y herramientas personalizadas deterministas; la segmentación de salida se aplica antes de que el agente actúe; la entrada y la salida pueden validarse en puntos bien definidos; la actividad deja rastro observable; la contención y la recuperación están diseñadas con cuidado y una lista de gobernanza que articula quién controla qué. No es un entorno al que haya que añadirle seguridad desde cero, sino que uno que ya proporciona los cimientos.

Figura 38: The Agent Access Model en Cloudflare

Para alcanzar un estadio óptimo solo hay que conectar y endurecer deliberadamente lo que ya existe. La adopción de la denegación por defecto frente a la confianza implícita, preferir credenciales efímeras y atribuibles a las que sean únicas y longevas. Vigilar los canales que se escapan a las políticas, convertir las listas de comprobación de gobernanza en revisiones vivas y extenderlo con el mismo rigor a las capacidades que se añaden al agente (servidores MCP, skills). Cada uno de los pasos son el movimiento desde el control disponible al control aplicado.

El modelo de madurez del despliegue se encuentra por debajo del nivel óptimo, a pesar de contar con capacidades que no son improvisadas, sino que son de primera clase y son habilitadas por la plataforma, pero la configuración, la automatización en la respuesta a incidentes y la gobernanza continua no son impuestas por defecto. Se han de aplicar en su configuración de forma consciente por el usuario. El factor condicional no es la tecnología, es el criterio ensamblador de dicha tecnología.

Figura 39:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

La seguridad de un agente se ha de construir partiendo de una buena base. Cloudflare proporciona, junto con Anthropic, esa base de forma óptima. El propósito de estas líneas ha sido ofrecer un criterio (los principios Zero Trust), con el que recorrer la distancia que separa un despliegue funcional a uno maduro. Continuar con la maduración no es eliminar defectos, sino ejercer la disciplina Zero Trust sobre una arquitectura que lo permite.

6.- Nota de Actualización.

En el momento de publicarse este artículo, Cloudflare ha lanzado su Agents Week, donde ha presentado, una nueva lista de capacidades que extienden las posibilidades de lo visto en esta pequeña guía, y exigen una lectura para aplicar con ellos los principios de Zero Trust de los que se ha hablado aquí.

Figura 40: Cloudflare Agents

7.- Bibliografía.

Anthropic. (22 de junio de 2026). Zero Trust for AI Agents.

Anthropic. (22 de junio de 2026). Intercept and control agent behavior with hooks

Anthropic. (22 de junio de 2026). Agent SDK overview

Anthropic. (22 de junio de 2026). Configure permissions

Anthropic. (22 de junio de 2026). Permission policies

Anthropic. (22 de junio de 2026). Get started with Claude Managed Agents

Anthropic. (22 de junio de 2026). Claude Managed Agents overview

Anthropic. (22 de junio de 2026). Tools

CISA. (abril de 2023). Zero Trust Maturity Model (Cybersecurity and Infrastructure Security Agency)

Cloudflare. (22 de junio de 2026). claude-managed-agents.

Cloudflare. (22 de junio de 2026). architecture.md.

Cloudflare. (22 de junio de 2026). securing-access.md

Cloudflare. (22 de junio de 2026). applying-egress-policies.md

Cloudflare. (22 de junio de 2026). agent-email.md

Cloudflare. (22 de junio de 2026). browser-rendering-tools.md

Cloudflare. (22 de junio de 2026). SSH with Access for Infrastructure

Cloudflare. (22 de junio de 2026). Mutual TLS

Cloudflare. (22 de junio de 2026). MCP server portals.

Cloudflare. (22 de junio de 2026). sandbox-sdk

Cloudflare. (22 de junio de 2026). Commands

Cloudflare. (22 de junio de 2026). Tunnels

Cloudflare. (22 de junio de 2026). Retries

Cloudflare. (22 de junio de 2026). Skills

Cloudflare. (22 de junio de 2026). isolate-vs-vm-sandboxes.md

Cloudflare. (22 de junio de 2026). snapshots-and-state-persistence.md

Cloudflare. (22 de junio de 2026). connecting-to-private-services.md

Cloudflare. (22 de junio de 2026). adding-custom-tools.md

Cloudflare. (22 de junio de 2026). customizing-sandboxes.md

Cloudflare. (22 de junio de 2026). issues/883

Cloudflare. (22 de junio de 2026). Security model

Cloudflare. (22 de junio de 2026). Container runtime

Cloud Security Alliance. (2025). Introduction to Software-Defined Perimeter. Certificate of Competence in Zero Trust

Cloud Security Alliance. (2025). Introduction to Zero Trust Architecture. Certificate of Competence in Zero Trust

Cloud Security Alliance. (2025). Zero Trust Planning. Certificate of Competence in Zero Trust

Microsoft. (22 de junio de 2026). Aspectos básicos de LLM

NIST. (agosto de 2020). Zero Trust Architecture. National Institute of Standards and Technology (Special Publication 800-207)

NSTAC. (23 de febrero de 2022). Zero Trust and Trusted Identity Management. President’s National Security Telecommunications Advisory Committee

OWASP. (2025). OWASP Top 10 para Aplicaciones de LLM

OWASP. (2026). OWASP Top 10 For Agentic Applications 2026. OWASP.

Un saludo,

Autor: Juan Luis Cuenca Ramos

Contactar con Juan Luis Cuenca Ramos

Computación Cuántica y Fusión Nuclear: La Receta para fabricar un "Sol en la Tierra"

noreply@blogger.com (Chema Alonso) — Wed, 05 Aug 2026 04:01:00 +0000

Desde hace casi un siglo, la Fusión Nuclear se presenta como el santo grial de la energía: la promesa de replicar en la Tierra la misma reacción que hace brillar al Sol, obteniendo cantidades inmensas de energía limpia, sin los residuos ni los riesgos de fusión del núcleo asociados a las centrales de fisión actuales. Pero como bien podréis imaginar, construir un ”Sol artificial” es más fácil de decir que de hacer.

Figura 1: Computación Cuántica y Fusión Nuclear.

La Receta para fabricar un "Sol en la Tierra"

Y no, esta vez el problema no está sólo en confinar un plasma a millones de grados con campos magnéticos. Hay un obstáculo mucho más mundano y del que se habla bastante menos: el combustible.

Figura 2: ”Boffins bet on quantum computers, AI supers to solve fusion fuel dilemma”

Este es precisamente el escenario que analiza el artículo de The Register titulado ”Boffinsbet on quantum computers, AI supers to solve fusion fuel dilemma”, donde se explica cómo el Departamento de Energía de EE.UU., la Cleveland Clinic e IBM han unido fuerzas para atacar este problema con una combinación de superordenadores, inteligencia artificialy ordenadores cuánticos.

Figura 3: Oak Ridge National Lab, Cleveland Clinic, and IBM Achieve

First-Known Computations of Fusion Materials on a Quantum Computers

Para conseguir la fusión necesitamos dos ingredientes: Deuterio y Tritio (Tritium), dos isótopos pesados del hidrógeno. El primero no supone ningún problema, ya que es abundante y se puede extraer del agua del mar. El segundo, en cambio, es el auténtico cuello de botella: el Tritio es radiactivo, se desintegra con rapidez y prácticamente no existe de forma natural en la Tierra.

El problema: un combustible que no existe (casi)

Para que os hagáis una idea de la magnitud del problema: la producción mundial de Tritio es de apenas unos pocos kilos al año, mientras que una sola central de fusión de un Gigavatio (GW) consumiría en torno a medio kilo al día. Es decir, todo el Tritio del planeta mantendría funcionando un único reactor durante unas pocas semanas.

Figura 4: Esquema resumido del problema de relacionado

con el ”combustible” de la fusión nuclear

Es como querer montar una red de gasolineras en un mundo donde el petróleo se vende por gotas. La conclusión es evidente: una central de fusión comercial no puede depender de un suministro externo, sino que debe fabricar su propio combustible mientras funciona.

La solución: una manta de sal fundida

La propuesta más prometedora consiste en envolver el reactor con una gruesa ”manta” de una sal fundida llamada FLiBe, compuesta por Flúor, Litio y Berilio. La idea es tremendamente elegante: cuando un neutrón sale disparado de la reacción de fusión y golpea un átomo de Litio-6 de la sal, este se rompe generando Helio y... ¡Tritio fresco! El Berilio, por su parte, multiplica los neutrones sueltos para que la ”cría” de combustible sea suficiente, mientras que el flúor y el litio mantienen la mezcla líquida y estable a las temperaturas infernales del reactor.

Figura 5: Esquema de un tokamak rodeado por la

manta de sal fundida donde se genera el Tritio.

Pero aquí llega la letra pequeña. Una vez generado el Tritio dentro de la sal, hay que sacarlo de ahí, y su comportamiento químico puede seguir dos caminos muy distintos:

Si el Tritio permanece libre en forma de gas: burbujea y sale solo de la mezcla. ¡Perfecto!

Si en cambio se une al flúor, forma fluoruro de Tritio: un compuesto corrosivo y muy difícil de extraer. Un auténtico quebradero de cabeza.

Predecir cuál de los dos caminos tomará requiere modelar la química de la sal con una precisión extrema. Y aquí los métodos clásicos se quedan cortos: la técnica habitual, la Teoría del Funcional de la Densidad (DFT), puede cometer errores de hasta el 10% en la energía libre del sistema, un margen inaceptable para responder a la pregunta clave.

Además, hacer experimentos reales con sales fundidas es carísimo y requiere instalaciones muy especializadas. ¿Os suena este patrón? Un problema de naturaleza cuántica que desborda a los ordenadores clásicos... ¡Es justo el tipo de tarea para el que nacieron los ordenadores cuánticos!

Supercomputación Cuántico-Céntrica: CPUs, GPUs y QPUs trabajando en equipo.

Como ya hemos comentado en otros artículos de este blog, los ordenadores cuánticos no vienen a sustituir a los clásicos, sino a complementarlos en problemas muy concretos. Y este trabajo es el ejemplo perfecto de esa filosofía, bautizada por IBM como Supercomputación Cuántico-Céntrica: combinar CPUs, GPUs & QPUs (procesadores cuánticos) para resolver juntos lo que ninguno puede resolver por separado.

La estrategia que han seguido los investigadores es muy ingeniosa:

Fragmentación del problema: mediante una técnica llamada wave function-based embedding, el cálculo de la molécula completa se trocea en fragmentos manejables llamados ”clusters”.

Reparto del trabajo: los ordenadores clásicos resuelven los clusters sencillos, mientras que el ordenador cuántico se encarga de los más complejos, aquellos con mayor entrelazamiento entre átomos, utilizando un algoritmo llamado Sample-Based Quantum Diagonalization (SQD).

Figura 6: Sample-Based Quantum Diagonalization (SQD)

Reconstrucción: finalmente, los ordenadores clásicos ”recosen” todos los fragmentos para obtener la solución de la molécula completa.

Lo curioso es que esta metodología no nació para la fusión: es la misma que utilizó laCleveland Clinic a principios de año para simular una proteína de 12.635 átomos. La ciencia es así de caprichosa, y una técnica desarrollada para biomedicina acaba siendo clave para la energía del futuro.

Figura 7: Modelado de la interacción entre el Tritio y

los clusters de átomos de la sal fundida FLiBe.

Con este enfoque, el equipo calculó las energías de nueve configuraciones moleculares de FLiBe (clusters de 21 iones cada una), con y sin Tritio, siendo la primera vez que se realizan este tipo de cálculos de materiales de fusión en un ordenador cuántico.

Figura 8: Quantum Computations on Fusion Blanket Molten Salts

Y lo más importante es que los resultados cuánticos igualaron a los métodos clásicos más exigentes. Puede parecer poco ambicioso ”sólo igualar”, pero es la prueba de concepto necesaria que demuestra que el camino cuántico funciona y está listo para escalar hacia donde los clásicos ya no llegan.

El futuro: un bucle de IA, superordenadores y cuántica

Este cálculo es solo una pieza de un plan mucho más ambicioso. El objetivo a largo plazo es construir un flujo de trabajo en bucle, asistido por agentes de inteligencia artificial, que funcione en tres etapas:

1. Cribado con IA: agentes de inteligencia artificial proponen y filtran candidatas a partir de una base de datos del ”Oak Ridge National Lab” con 70 años de investigación en sales fundidas, estimando cuánto tritio generaría cada sal y si sus propiedades térmicas son adecuadas.

2. Simulación clásica: las sales más prometedoras pasan a los superordenadores, que las modelan átomo a átomo. Como estas simulaciones son carísimas, se emplean ”sustitutos” de IA entrenados para reproducir la física a gran velocidad.

3. Precisión cuántica: el ordenador cuántico entra donde la DFT se queda corta: la química de alta precisión que decide dónde se une el tritio. Los resultados realimentan el bucle, afinando la siguiente ronda de candidatas.

El sueño de los investigadores es que, en el futuro, los ingenieros de fusión puedan diseñar y validar una sal fundida completamente por ordenador antes de mezclarla y calentarla en un laboratorio, ahorrando años de experimentos y cantidades ingentes de dinero.

Figura 9: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

Eso sí, seamos honestos con las limitaciones: el problema completo requiere modelar una manta de sal de un metro de grosor con del orden de un cuatrillón de partículas, algo que seguirá fuera del alcance de la química computacional durante mucho tiempo. El plan inmediato es más modesto pero realista: aumentar el tamaño de los clusters mucho más allá de los 21 iones actuales y calcular los cientos de configuraciones que exige el problema completo, no solo nueve.

Figura 10: 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

En definitiva, estamos presenciando cómo tres de las tecnologías más punteras de nuestro tiempo (la Inteligencia Artificial, la Supercomputación y la Computación Cuántica) dejan de competir entre sí para unir fuerzas contra uno de los grandes problemas de ingeniería de la humanidad. Los ordenadores cuánticos ya no solo prometen revolucionar el futuro: están ayudando a construirlo. La pregunta es inevitable: ¿será la cuántica la pieza que por fin encienda nuestro propio sol en la Tierra?

Figura 3: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Si te interesan estos temas, te recomiendo que te apuntes al Foro Online Público que funciona desde Septiembre del año pasado en MyPublicInbox, donde se comparten temas de Quantum & Post-Quantum Securrity, así que si quieres estar informado puedes entrar libremente y suscribirte. Y si quieres más, apúntate al curso de Quantum y Post-Quantum Computing para Ciberseguridad.

Saludos,

Autor: Daniel Romero Ruiz

Contactar con Daniel Romero Ruiz

Otros artículos sobre Quantum Computing publicados:

Cómo desplegar Zero Trust para Agentes IA en Cloudflare (3)

noreply@blogger.com (Chema Alonso) — Tue, 04 Aug 2026 04:01:00 +0000

Continuando lo visto en la primera parte de esta serie, y en la segunda, continuamos en este apartado con cómo configurar modelos de Zero Trust para Agentes IA utilizando las tecnologías de Cloudflare, comenzando ahora con la validación de los datos de entrada y los datos de salida, un tema de los más importantes.

Figura 23: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (3)

En la próxima parte daremos por terminado este artículo, pero antes vamos a recorrer las fortificaciones que aún nos quedan por hacer en un modelo Zero Trust y cómo hacer éstas con Cloudflare.

4.4.- Validación de entrada y salida de datos.

El principio.

La segmentación traza el mapa de con quién puede hablar el agente, este control vigila que viaja por esas conexiones. Tiene dos caras. En la entrada, el problema es la inyección. Como se estableció en la premisa, el agente no distingue de forma fiable una instrucción legítima de una orden maliciosa incrustada en los datos que procesa (un correo, una página web, el resultado de una herramienta).

OWASP lo recoge como el secuestro objetivo del agente (ASI01- Agent Goal Hijack), una de sus categorías primarias. En la salida, el problema es la exfiltración: que el agente, comprometido o no, emita datos que no deberían salir.

Figura 24: ASI01- Agent Goal Hijack

El eBook de Anthropic articula este control con claridad: la validación de entrada bloquea los intentos de manipulación en la frontera, rechazando instrucciones maliciosas antes de que el agente las procese y los controles de salida restringen lo que el agente puede producir, limitando la fuga de datos incluso cuando un atacante logra comprometer su comportamiento. La idea rectora es que el agente no puede ser su propio filtro. La validación debe ser un filtro externo, previo al procesamiento.

Figura 25: Prompt Injection

Hay un matiz propio del mundo agéntico que conviene no ignorar. La validación de entradas no se traslada directamente desde la seguridad tradicional. La inyección SQL, tiene patrones definidos y campos acotados, pero las entradas de un agente son libres e impredecibles, lo que hacen que sean insuficientes dichas reglas. Aun así, se puede validar contra esquemas esperados, imponer longitudes máximas y rechazar patrones conocidos antes de que la entrada llegue al agente.

Dónde se sitúa hoy el ecosistema de Cloudflare.

El despliegue ofrece varios puntos donde insertar esta validación, aunque conviene señalar un hecho destacable. La documentación describe los canales por donde entra el contenido externo, pero no afirma que exista un filtrado de contenido automático sobre ellos. El filtro, en buena medida, es algo que quien despliega debe construir en los puntos que la plataforma habilita.

El correo es un ejemplo de entrada no confiable. Cada agente puede tener un buzón y cuando llega un mensaje, el agente recibe un evento que le indica que un correo ha llegado y le ofrece leerlo. Este cuerpo es contenido externo que entra en el contexto del agente: un vector de inyección indirecta. La documentación describe el mecanismo, pero no un filtrado del contenido. Ese filtrado es responsabilidad de quien despliega. Lo mismo ocurre con la navegación web: recuperar una página es ingerir contenido no controlado.

Figura 26: Agent Email en Cloudflare

El punto de inserción natural para la validación es la herramienta personalizada, y a presentada en 4.2. Su esquema de entrada, declarado y válido, rechaza llamadas con forma inesperada antes de ejecutar nada. Su cuerpo es el lugar donde la propia documentación sugiere validar entradas, Redactar información sensible o comprobar autorización antes de hacer el trabajo. Esa redacción de información sensible es, precisamente, en control de salida al filtrar lo que vuelve al agente o sale hacia un servicio.

Para la ejecución de comandos, el Sandbox SDK ofrece una mitigación concreta contra la inyección de shell: pasar los datos por la entrada estándar en lugar de interpolarlos en el comando, lo que permite procesar entrada de usuario sin riesgo de inyección. La documentación lo ilustra con un caso donde una cadena maliciosa, pasada por entrada estándar, resulta inofensiva, mientras que incrustada en el comando sería peligrosa. El propio modelo de responsabilidad del Sandbox sitúa además la validación y el saneamiento de entradas explícitamente del lado de quien despliega, no de la plataforma (Cloudflare, 2026u).

Figura 27: Cloudflare Commands en Sandbox

Y en la dimensión de salida, el ecosistema de Cloudflare One aporta control sobre el canal de los servidores MCP, por el que el agente invoca herramientas externas. El portal de servidores MCP permite curar qué herramientas quedan expuestas (desactivando herramientas individuales o derivando a una lista de permitidos para mostrar solo un subconjunto) y somete el acceso a cada servidor a la identidad corporativa, imponiendo a qué servidores accede cada quién con independencia de las políticas del propio servidor. Además, registra las peticiones individuales realizadas con las herramientas del portal. Curar el canal y auditarlo es, en este contexto, una forma de control sobre lo que el agente puede llegar a enviar a través de él.

Continuando la maduración Zero Trust.

El primer avance de maduración consiste en reforzar progresivamente el filtro de entrada. Un punto de partida razonable es validar formatos contra esquemas esperados, imponer longitudes máximas y rechazar entradas manifiestamente malformadas. Sobre esa base, incorporar detección de patrones de ataque conocidos y filtrado de cargas codificadas y en los entornos más exigentes, delimitar de forma explícita el contenido no confiable para que el modelo lo trate como inseguro (la técnica de spotlighting). El eBook de Anthropic describe esta progresión y aporta criterios concretos para cada estadio de forma coherente con el principio Zero Trust de no confiar en la entrada y filtrarla en la frontera.

El segundo avance es tratar todo el canal por el que entra el contenido externo (correo, web, resultado de herramientas) como no confiable por defecto, e interponer en cada uno un punto de validación antes de que su contenido alcance el contexto del agente. La forma natural de lograrlo en este despliegue es encapsular esos canales tras herramientas personalizadas que validen y cuando proceda, saneen o delimiten el contenido, en lugar de dejar que entre directamente.

Figura 28:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

El tercer avance es simétrico, en la salida: definir qué clases de datos no deben abandonar nunca el entorno y materializar esa decisión en los puntos disponibles (la redacción dentro de las herramientas personalizadas y la curaduría y auditoria del canal MCP), de modo que la exfiltración quede dificultada incluso si el agente es manipulado para intentarla.

4.5.- Observabilidad y comportamiento.

El principio.

Los controles anteriores deciden que puede hacer el agente, la observabilidad nos permite saber está ocurriendo realmente en el sistema. Es un requisito indispensable por el cual pueden verificarse, ajustarse y defenderse los demás controles, ante un incidente.

Por este motivo CISA eleva la visibilidad y analítica a la categoría de capacidad trasversal de toda arquitectura Zero Trust. En la práctica, la visibilidad consiste en recopilar y observar la telemetría, los registros y los eventos que generan el entorno. El análisis de esta información es lo que verdaderamente permite actualizar las políticas de acceso, agilizar la respuesta a incidentes y construir un perfil de riesgo para tomar medidas proactivas antes de que el ataque se materialice. NIST, siguiendo la misma línea, sitúa la monitorización continua entre los fundamentos de la arquitectura Zero Trust.

Figura 29: Capacidades Transversales de CISA para Zero Trust

En un agente, la obsevabilidad tiene una exigencia añadida, no basta con registrar el resultado de una acción, hay que poder reconstruir la cadena de acciones que llevó a ella (que entrada recibió, qué herramienta invocó, con qué argumentos, con qué resultado). Sólo así puede distinguirse un comportamiento legítimo de uno inducido por una inyección y solo así atribuirse una acción a quien la lanzó.

Dónde se sitúa hoy el ecosistema Cloudflare.

El despliegue es en esta dimensión, notablemente sólido, con un posible punto ciego importante que ya se ha señalado.

La sesión es, por diseño, un registro. Como se describió en la sección 3, el historial de eventos de cada sesión persiste y se puede recuperar íntegro: la conversación, los turnos, los resultados de herramientas. La sesión no es solo ejecución, es también su propia bitácora.

Sobre el acceso al panel, cuando se coloca Cloudflare Access delante, se obtiene un registro de auditoria sin escribir código: Access registra cada petición autenticada, lo que resulta útil cuando una sesión hace algo sorprendente y se quiere saber quién la lanzó. La identidad de quien opera queda ligada a lo que la sesión hace.

Figura 30: Securing Access

Sobre el comportamiento interno del agente, los dos backends ofrecen vías distintas. En MicroVM existe un terminal en vivo a través del panel, que permite ver exactamente lo que el agente vio. En Isolate, que no tiene shell, la observabilidad se obtiene de los registros de Workers, donde el despachador de herramientas registra cada nombre de herramienta y su resultado. En ambos casos, la actividad del agente deja rastro consultable.

El punto ciego es el ya conocido y aquí cobra todo el sentido: las herramientas del servidor de Anthropic se ejecutan fuera de la cuenta de Cloudflare y no dejan ninguna traza (ni registro, ni auditoría). Lo que no se ve no se puede vigilar. Por eso el ecosistema ofrece variantes equivalentes de navegación que sí recorren en la cuenta propia y cuyas peticiones son observables en los registros de la cuenta. La diferencia entre una y otra opción es, exactamente, la diferencia entre tener y no tener observabilidad.

Continuando la maduración Zero Trust.

El primer avance es centralizar y correlacionar lo que hoy está disponible pero disperso: el historial de eventos de sesión, los registros de acceso de quien la lanzó y los registros del despachador de herramientas. Reunidos y vinculados por el identificador de sesión, permiten reconstruir la cadena completa (quién lanzó qué sesión, qué hizo el agente, con qué herramientas y resultados) que la investigación de un incidente requiere.

El segundo avance es eliminar los puntos ciegos por decisión de diseño: preferir, para toda navegación web, las variantes observables que corren en la cuenta propia y mantener desactivadas las que no dejan traza. Una observabilidad con huecos conocidos es una observabilidad que un atacante usará precisamente por esos huecos.

El tercer avance lleva la observabilidad del registro pasivo a la detección activa. Disponer de los registros es la base; estadio maduro es analizarlos para construir el perfil de riesgo del que habla la CISA (establecer que comportamiento es normal para un agente y alertar sobre desviaciones, como una herramienta que nunca se invoca, de pronto se le hace una llamada o un volumen de salida anómalo) de modo que la observabilidad no sólo explique los incidentes después, sino que ayude a detectarlos mientras ocurren.

4.6.- Contención y recuperación.

El principio.

Zero Trust asume que las defensas pueden fallar y que un sujeto puede acabar comprometido. Por eso exige, además de prevenir, contener el daño cuando ocurre y poder volver a un estado bueno conocido. La contención busca limitar el radio de alcance (blast radius), es decir que un agente comprometido afecte lo mínimo. Y la recuperación, restaura la operación sin arrastrar el estado corrupto.

Figura 31: Blast Radius

La taxonomía OWASP para aplicaciones agénticas recoge expresamente estos mecanismos: interruptores de parada, límites de radio de alcance, aislamiento entre el planificador y el ejecutor y contención en tiempo de ejecución, como defensas frente a la propagación de errores y el abuso entre agentes. En un agente, esto se concreta en tres capacidades: poder detenerlo de inmediato cuando se detecta un comportamiento anómalo, acotar por diseño lo que su compromiso pueda alcanzar y restaurar su entorno a un punto limpio si propagar aquello que hubiera quedado corrompido.

Dónde se sitúa hoy el ecosistema Cloudflare.

El despliegue ofrece una base de contención y recuperación que cubre las tres capacidades, con un matiz en la resiliencia de la cola de trabajo.

La parada inmediata existe como operación de primera clase: entre las funciones que el plano de control ejerce con su credencial está la de forzar la detención de una sesión. Hay, además, una contención por diseño que opera sola: las sesiones no se ejecutan indefinidamente, sino que se detienen automáticamente tras un periodo de inactividad. Una sesión olvidada no queda viva indefinidamente como superficie de ataque.

El aislamiento como contención ya se trató: cada sandbox corre en su propia máquina virtual, de modo que el compromiso de uno no alcanza a los demás y la segmentación de salida acota con quién puede comunicarse un agente comprometido. La contención del radio de alcance no es, por tanto, un añadido. Está en la arquitectura.

La recuperación está cuidadosamente diseñada: El directorio de trabajo de cada sesión MicroVM se preserva mediante copias a almacenamiento de objetivos, que se restauran al reanudar. Isolate persiste su estado de forma transparente. Y el diseño es defensivo en un punto importante: nunca se restuaran sobre un contenedor en ejecución y si una restauración falla, el sistema registra el fallo y arranca con un directorio limpio en lugar de bloquearse. Es una recuperación que prioriza no propagar el estado dañado.

El matiz que señalar está en la resiliencia de la cola de trabajo del entorno de ejecución. La documentación del sistema de colas advierte de que no existe una cola de mensajes fallidos. Una tarea que falla se elimina y se recomienda implementar la persistencia propia, los reintentos bloquean la cabeza de la cola y no hay un cortacircuitos.

Continuando con la maduración Zero Trust

El primer avance es convertir la parada manual en respuesta automática: vincular la detección de comportamiento anómalo (del control de observabilidad) con la función de detención, de modo que una desviación grave no dependa de que un humano esté mirando. Es el interruptor de parada OWASP llevado a su forma efectiva, disparado por una señal, no solo por una persona.

El segundo avance es endurecer el radio de alcance combinando los controles ya descritos: segmentación de salida estricta, identidades de alcance acotado e inyección de credenciales que el agente no custodia. Cada uno reduce lo que un compromiso puede tocar; juntos, materializan el límite del radio de alcance que pide la taxonomía agéntica.

Figura 32: Snapshots & Persistencia en Cloudflare

El tercer avance atañe a la resiliencia de las tareas y a la retención de los datos de recuperación. Por un lado, implementar la persistencia propia de las tareas críticas que la cola no garantiza, de modo que un fallo no las pierda en silencio. Por otro, gobernar la retención de las copias automáticamente, así que definir y aplicar una política de retención es responsabilidad de quien despliega, un punto que enlaza directamente con la gobernanza de datos de la sección siguiente.

Termina en: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

Un saludo,

Autor: Juan Luis Cuenca Ramos

Contactar con Juan Luis Cuenca Ramos

Digi Americas LATAM CISO Summit 2026: 11 de Septiembre estaré en México

noreply@blogger.com (Chema Alonso) — Mon, 03 Aug 2026 06:46:06 +0000

Hace mucho, mucho, mucho tiempo que no doy una conferencia en México, y la verdad es que ya tenía ganas de regresar. Y será en Septiembre, ya que estaré como ponente en el Digi Americas LATAM CISO Summit 2026, que tiene lugar en Cancún del 10 al 12 de Septiembre.

Figura 1: Digi Americas LATAM CISO Summit 2026:

11 de Septiembre estaré en México

La lista de ponentes es espectacular, con Adolfo Fabrega, Alberto Yépez, Alexandra Rose, Altagracia Gomez, André Molina, Ariel Waissbein, H.E. Ivan Duque, H.E. Toomas Hendrik Ilves, Heidy Rocha, Julissa Cruz Abreu como ponentes destacados de una enorme lista.

Figura 2: Speakers de Digi Americas LATAM CISO Summit 2026

Mi charla, en concreto, será el día 11 de Septiembre a las 09:50, para hablar del mundo del Hacking y la Inteligencia Artificial, que ya sabéis que es un tema que me tiene absorbido los últimos años, así que será una charla sobre los temas que me apasionan.

Figura 4: Mi charla en el Digi Americas LATAM CISO Summit 2026

Pero ya que estoy allí, tendré reuniones, me haré las fotos que pueda, y lo mismo me llevaré algunos de mis libros de Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignmen por si alguien los quiere tener, ya que voy a estar por allí.

Figura 5:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Así que, si estás por México, o por la región, y estabas pensando en ir al Digi Americas LATAM CISO Summit 2026, que sepas que yo estaré por allí. Y si quieres que nos reunamos, que te lleve o un libro, o solo verme, puedes contactar conmigo para ello.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

El Agente AI Musical que trae los Conciertos de los Músicos en MyPublicInbox

noreply@blogger.com (Chema Alonso) — Sun, 02 Aug 2026 04:01:00 +0000

Desde comienzo de este año MyPublicInbox está transformándose con Agenteic AI Ops, para incrementar la experiencia de uso, automatizar tareas, potenciar más a los perfiles públicos y dotar cada vez de más capacidades a todos los usuarios. Hace poco os hablaba de MyPulicGPT para que los perfiles públicos puedan conocer su huella digital en los buscadores de IA, y del Canal eMail de MyPublicInbox, y hoy os hablo de nuestro Agente IA Musical, que se encarga de mantener actualizada la agenda de conciertos de todos los músicos de la plataforma.

Figura 1: El Agente AI Musical que trae los Conciertos de los Músicos en MyPublicInbox

Como ya sabéis, a principio de año os anunciamos que MyPublicInbox había adquirido la plataforma LinkMusic, con el objetivo de incrementar los servicios en nuestro vertical de música. Hoy, gracias a nuestro Agente AI musical, estamos actualizado los miles de conciertos que dan los músicos de MyPublicInbox.

Figura 2: Conciertos de David Summers en su perfil

Los podéis ver en el perfil de cada usuario, como podéis ver con David Summers y su gira de Hombres G, en la parte derecha de su buzón púbico, pero con una sección para poder ver todos los que ya están publicados.

Figura 3: Sección de Conciertos completa de David Summers

Por ejemplo, mis queridos Despistaos, que comienzan su pedazo de Gira de "Un millón de Madrugadas", tienen ya también publicadas todas sus fechas en le buzón del grupo.

Figura 4: Gira de "Un millón de madrugadas" de Despistaos

Pero también se irá publicando en cada uno de los miembros de la banda, como en este caso el gran Krespo, gracias a que nuestro Agente IA Musical está buscando cómo potenciar al máximo los trabajos de los perfiles púbicos.

Figura 5: Conciertos de Krespo

Y para todos los demás, pues una forma de que no se te escape nada. De hecho, si sigues a uno de los músicos, la plataforma te enviará un mensaje interno para avisarte cuándo se ha producido la publicación de nuevos conciertos, para que no se te escape nada de lo que hacen los músicos de MyPublicInbox.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

La ética como “Safety Net”: Por qué la IA responsable acelera la innovación (y no la frena)

noreply@blogger.com (Chema Alonso) — Sat, 01 Aug 2026 05:07:00 +0000

Cuando se habla de ética y regulación de la inteligencia artificial, la reacción más habitual -también entre gente muy sensata- es pensar en un freno. Un comité más, un formulario más, un abogado más entre la idea y el producto. Yo llevo defendiendo justo lo contrario desde hace años, y con RAIGHT.ai, la startup que he cofundado junto a Miguel Ángel Liébanas, Laura González, Ricardo Palomo e Idoia Salazar, hemos intentado demostrarlo con una plataforma, no solo con argumentos.

Figura 1: La ética como “Safety Net” - Por qué la IA

responsable acelera la innovación (y no la frena)

La tesis es sencilla: la ética by design no es un obstáculo para innovar rápido, es la condición para poder hacerlo con seguridad. Y como en tantas cosas de la vida, conviene explicarlo con sobriedad holandesa, sin caer ni en el alarmismo (“la IA nos va a destruir”) ni en la ingenuidad (“ya se regulará solo”).

El problema: demasiados principios, poca práctica

Desde 2018 llevamos trabajando en IA ética y responsable, primero desde OdiseIA, el observatorio que fundamos en 2019 y que hoy es referencia internacional en la materia. En todo este tiempo hemos visto proliferar recomendaciones —UNESCO, OCDE, Consejo de Europa— y regulaciones, con el AI Act europeo a la cabeza.

Figura 2: Plataforma RAIGHT

Todas apuntan en buena dirección, pero -aparte del AI Act- comparten un mismo defecto: se quedan en principios de alto nivel (“evitar el sesgo”, “garantizar la transparencia”) sin decir cómo hacerlo en un caso de uso concreto.

Figura 3: Gestión centralizada de riesgos de IA

Es la diferencia entre decirle a un desarrollador “cuidado con el sesgo” y decirle “este sistema de selección de personal puede discriminar a mujeres en roles técnicos por el histórico de contrataciones; aquí tienes el requisito concreto para mitigarlo”. La primera frase genera ansiedad. La segunda, acción.

La solución: gobernanza automatizada, con supervisión humana

RAIGHT.ai nació en el verano de 2024 para resolver justo ese salto entre la teoría y la práctica. La plataforma parte de un inventario propio de más de 800 riesgos éticos de IA, construidos analizando con IA generativa más de 15.000 incidentes reales recogidos por repositorios como el AI Incident Monitor de la OCDE, el AI Risk Repository del MIT o AIAAIC (AI, Algorithmic and Automation Incidents and Controversies).

Figura 4: Gestión de riesgos accionable

A cada riesgo le hemos asociado, también con ayuda de IA generativa y revisión humana posterior, los requisitos de mitigación concretos y accionables. (Ver Benjamins et al., “Responsible AI: from theory to practice”, capítulo del próximo Handbook of AI Ethics de Springer.) El flujo, en la práctica, es este:

Registro automático del caso de uso: Se sube documentación del sistema de IA (una ficha técnica, una descripción funcional) y la plataforma extrae automáticamente los datos relevantes.

Detección inteligente de riesgos: Con un clic, la plataforma compara el caso de uso contra el inventario y propone los riesgos aplicables. El equipo humano tiene que confirmarlos explícitamente; nada se acepta “a ciegas”, precisamente para evitar el riesgo de sobre-confianza en el propio sistema.

Lista de requisitos accionable: Para cada riesgo confirmado, aparecen los requisitos de mitigación correspondientes, documentados, asignados y trazables hasta su resolución.

Lo hemos probado, entre otros, con COMPAS, el conocido sistema estadounidense de evaluación de riesgo de reincidencia usado en el ámbito judicial: la plataforma identifica sin dificultad los riesgos de discriminación algorítmica que ya denunciaron periodistas e investigadores hace años, y propone las salvaguardas que deberían haberse aplicado desde el diseño.

Figura 5: Identificación Inteligente de riesgos de IA

Por qué esto es bueno para el negocio (y no solo para la conciencia)

Aquí es donde quiero insistir, porque es el mensaje que peor se entiende: la IA responsable no compite con la innovación, la habilita. Hay al menos tres razones de peso:

Innovación más rápida y barata: Cuando los riesgos se detectan al principio del diseño, corregirlos cuesta una fracción de lo que cuesta hacerlo después del lanzamiento, con la reputación ya dañada. Un equipo que sabe que tiene esta “red de seguridad” puede permitirse experimentar más, no menos.

Confianza de clientes y talento: El 93% de los consumidores valora la responsabilidad social de las empresas que eligen, y el 64% del talento digital prioriza estos valores a la hora de elegir dónde trabajar. En un mercado donde captar y retener talento técnico es una batalla constante, no es un dato menor.

Atractivo para inversores: Cada vez más fondos incorporan criterios ESG a sus decisiones, y la IA ética entra de lleno en la “S” de social. Hay ya rankings, como el de Ranking Digital Rights o el modelo de madurez de la GSMA, que puntúan explícitamente la gobernanza responsable de la IA.

Y hay un cuarto argumento, más pragmático: bajo el AI Act, sólo los sistemas de riesgo alto o limitado tienen obligaciones específicas. Con una plataforma que registra todos los casos de uso y su perfil de riesgo, una organización puede ir más allá del mínimo regulatorio con un esfuerzo adicional pequeño, y convertir el cumplimiento en un activo de confianza en lugar de en un ejercicio defensivo.

“Human in the loop”

Lo que proponemos con RAIGHT.ai no es sustituir el criterio humano por un algoritmo que dice “sí” o “no”. Es automatizar lo automatizable: la búsqueda en un inventario de miles de riesgos conocidos, la generación de la primera versión de los requisitos, para que las personas dediquemos el tiempo a lo que de verdad requiere criterio: decidir, priorizar, y responder por esas decisiones. La supervisión humana no es un trámite en nuestra metodología, es una pieza de diseño.

Figura 6: Contacta con nosotros para una Demo de RAIGHT

Resumiendo una cita famosa de Johan Cruyff, “jugar bien no es dar mil pases, es dar el pase justo en el momento justo”. La IA responsable no consiste en poner mil controles, sino en poner los controles justos, en el momento justo del ciclo de vida del sistema, es decir, al principio, cuando aún se puede diseñar bien, no al final, cuando solo queda apagar fuegos.

Nota de transparencia: este artículo ha sido redactado con la asistencia de herramientas de IA generativa a partir de material propio (paper académico, presentación corporativa y contenidos de raight.ai), con revisión y edición humana final.

Autor: Dr. Richard Benjamins, CEO RAIGHT.ai

Contactar con el Dr. Richard Benjamins

Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity

noreply@blogger.com (Chema Alonso) — Fri, 31 Jul 2026 05:01:00 +0000

El próximo mes de Octubre de 2026 da comienzo el Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity que se realizará en sesiones los jueves y viernes por la tarde y los sábados por la mañana online, hasta el próximo mes de Marzo de 2027, aprendiendo con profesionales que trabajan en ciberseguridad.

Figura 1: Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity

Este bootcmap online cuenta con más de 100 horas de sesiones online en directo, con acceso a retos de ciberseguridad, un curso de scripting con Bash, un curso de scripting con Python y un curso de Metasploit. Además, el bootcamp, que es de nivel intermedio, tiene cuenta con una sesión de orientación para los asistentes, además de tener 1 año de tutorización y derecho a examen.

Figura 2: Contenidos del Bootcamp de Ciberseguridad Defensiva y Ofensiva

Además, se entregan los libros de "Hacking IA" y "The Art of Pentesting" para todos los alumnos, junto con 2.000 Tempos de MyPublicInbox para contactar con los expertos de cibeseguridad de la plataforma.

Figura 3:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

El bootcamp está pensado para recién licenciados en Ingeniería Informática o personas que deseen enfocar su carrera profesional al hacking ético y el pentensting. También para perfiles junior que estén ya trabajando pero que requieran de un nivel de especialización mayor; perfiles profesionales con experiencia en algún ámbito de la ingeniería, programación o administración de sistemas y que deseen dar un cambio a su carrera profesional adentrándose en el ámbito del hacking ético, y para miembros de las Fuerzas y Cuerpos de Seguridad del Estado relacionados con el ámbito de la seguridad de la información y la ciberdelincuencia.

Figura 4: Equipo docente del Bootcamp de Ciberseguridad Defensiva y Ofensiva

El equipo docente es espectacular, con Pablo González, Álvaro Núñez-Romero, Ángel A. Núñez, Alejandro Amorín, Rafa García, Ainoa Guillén, Fran Ramírez, Rafa Sánchez, José Luis Martínez, Valentín Martín o Carmen Torrano, entre otros.

Figura 5: "The Art of Pentesting" El libro de Pablo González en

0xWord para formarse como pentester

La evaluación final de los alumnos se realizará mediante un Trabajo de Fin de Bootcamp que habrá que presentar y defender. Una vez el alumno haya completado el Bootcamp, realizado el respectivo proceso de evaluación y superado la calificación mínima de corte, se le remitirá un certificado digital del curso con sus datos. Tienes aquí toda la información del Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity

Autor: Miguel Ángel Martín, CEO de HackBySecurity

Contactar con Miguel Ángel Martín de HackBySecurity