"Si tú no trabajas por tus sueños, alguien te contratará para que trabajes por los suyos”

Steve Jobs

Afiliado
Dominios3Euros

Un informático en el lado del mal

Blog personal de Chema Alonso sobre sus cosas.
  • Cuando hablamos de Inteligencia Artificialen las organizaciones, lo habitual es asociarla con ChatGPT, Claude o cualquier otra herramienta a la que accedemos desde un navegador. Esta asociación está bastante extendida entre las empresas menos tecnológicas y, en muchos casos, responde al desconocimiento de cómo funciona realmente esta tecnología. 


    La Inteligencia Artificial necesita, recursos de computación, almacenamiento y sistemas capaces de procesar información. La capacidad de estos modelos para realizar determinadas tareas mejor o peor que las personas es otra discusión que dejaremos para otro artículo. Lo interesante aquí es comprender cómo accedemos a esta tecnología, qué ocurre con nuestros datos y qué capacidad real tenemos para aplicar medidas de control que reduzcan los riesgos.
    En muchas organizaciones he observado que la gestión de estos riesgos se apoya principalmente en políticas de uso, herramientas DLP e instrucciones incorporadas a los Prompts para limitar el comportamiento de la IA. No es la solución.

    Estas medidas pueden ayudar, pero presentan limitaciones importantes.

    Un Prompt no constituye una barrera de seguridad fiable: Y si has visto los muchísimos artículos sobre las técnicas de Jailbreak, los ataques de Prompt Injection, o el desalineamiento de Asistentes IA y servicios digitales, lo tendrías que tener más que claro.
    Los modelos pueden recibir instrucciones adversarias, interpretar incorrectamente las restricciones o generar comportamientos no previstos. 
    Es precisamente una de las cuestiones sobre las que Chema Alonso insiste habitualmente en sus investigaciones y charlas sobre seguridad en IA. Para comprender mejor estas limitaciones, vamos a comparar tres formas de utilizar esta inteligencia artificial.

    1. Acceso directo mediante navegador

    Es el modelo más conocido. La organización contrata licencias de un servicio de Inteligencia Artificial y sus empleados acceden directamente desde el navegador. En realidad, estamos consumiendo un servicio de un proveedor externo, bajo determinadas condiciones contractuales, configuraciones de privacidad y mecanismos de seguridad que solo el propio proveedor impone. Cuando un empleado introduce información en el chat y pulsa enviar, esos datos llegan a la infraestructura del proveedor.

    Figura 5: Flujo de información desde el usuario hasta
    el proveedor de IA mediante navegador.
     
    La organización puede establecer políticas de uso, aplicar controles DLP, restringir accesos y exigir garantías contractuales. Sin embargo, las funciones de protección más avanzadas suelen estar vinculadas a planes empresariales con costes adicionales, lo que puede dificultar su adopción por parte de pequeñas y medianas organizaciones.

    Además, el comportamiento humano introduce una dificultad adicional. Un empleado puede compartir información confidencial, ignorar las instrucciones corporativas o utilizar herramientas de IA sin autorización, una práctica conocida como Shadow AI. Este fenómeno dificulta la aplicación de medidas de control y aumenta el riesgo de exposición de información fuera del perímetro organizativo. La exposición del dato puede producirse antes de que cualquier instrucción dirigida al modelo tenga oportunidad de intervenir.

    2. Integración mediante API y backend corporativo

    El segundo método permite introducir una diferencia importante. En este escenario, la organización desarrolla una aplicación con su propio front-end y backend. El empleado interactúa con esa aplicación y es el backend quien se comunica con el modelo del proveedor mediante una API. Esta arquitectura permite aplicar medidas técnicas antes de que la información salga de la organización.

    Podemos clasificar los datos, eliminar información innecesaria, aplicar técnicas de pseudonimización, verificar permisos, limitar las operaciones autorizadas y registrar las solicitudes. También podemos revisar las respuestas del modelo antes de utilizarlas.

    Figura 6: Flujo de información mediante una aplicación corporativa,
    backend y API de un proveedor externo de IA.

    El proveedor continúa procesando la información que recibe, pero la organización puede controlar mejor qué envía y para qué finalidad. La diferencia está en incorporar controles técnicos directamente al flujo de información, reduciendo la dependencia de las decisiones individuales de cada empleado. El riesgo permanece, aunque una implementación correctamente diseñada puede reducir tanto la exposición como la probabilidad de determinados incidentes.

    3. Despliegue de inteligencia artificial en infraestructura local

    El tercer método consiste en ejecutar el modelo dentro de la propia infraestructura de la organización. Actualmente existen modelos de inteligencia artificial con capacidades avanzadas que pueden desplegarse en servidores internos, como gpt-oss-20B (OpenAI), Mistral Small 3.1 de 24B, Gemma 3 de 27B (Google), Qwen3 de 32B (Alibaba), LLaMA de 65B (Meta, primera generación), Llama 3.3 de 70B y gpt-oss-120B (OpenAI). 

    Estos modelos pueden ejecutarse utilizando recursos propios de CPU, GPU, memoria y almacenamiento, con requisitos técnicos que varían según su tamaño, arquitectura y nivel de cuantización. En esta arquitectura, el front-end, el backend, el modelo y los sistemas de almacenamiento pueden permanecer dentro del mismo perímetro organizativo. Estas arquitecturas son muy usadas por los expertos que usan IA para hacer Seguridad Ofensiva y Pentesting.

    Esto permite controlar directamente el procesamiento, los accesos, los registros de actividad, la retención de información y las conexiones con otros sistemas. También ofrece la posibilidad de operar sin enviar los datos utilizados durante la inferencia a proveedores externos, siempre que las dependencias, la telemetría y las integraciones estén correctamente configuradas.

    Figura 8: Flujo de información con un modelo de IA local dentro
    del perímetro de la organización y sus dependencias externas.

    La contrapartida es que la organización asume la responsabilidad de proteger y mantener toda esa infraestructura. Una mala configuración, un usuario con privilegios excesivos, un conector vulnerable o un modelo expuesto pueden generar incidentes igualmente graves.

    La arquitectura es una medida de control

    Los tres escenarios permiten utilizar inteligencia artificial, pero presentan diferencias importantes en la exposición de los datos, la dependencia de terceros y la capacidad de aplicar medidas de seguridad. Contratar licencias, integrar una API o desplegar un modelo local no determina automáticamente el nivel de seguridad de una organización.

    La cuestión es comprender el recorrido de la información y establecer controles eficaces en cada punto de ese recorrido.Las políticas y las instrucciones pueden orientar el comportamiento de los usuarios y de los modelos. Las medidas técnicas permiten imponer restricciones verificables, aunque tampoco ofrecen garantías absolutas.


    Al final, todo se reduce a entender por dónde circulan nuestros datos, quién los procesa y hasta dónde llega nuestra capacidad de control. Utilizar Inteligencia Artificiales relativamente sencillo; gestionar sus riesgos requiere conocer bien cómo funciona y cómo la hemos integrado en nuestra organización.


    Figura 9: CDIE: Risk Extension and Traceable Uncertainty in Organizational Al Risk Assessment.

    Y aprovechando que hablamos de riesgos y consecuencias, estoy desarrollando CDIE, una investigación exploratoria centrada en identificar y documentar las posibles consecuencias de las decisiones relacionadas con inteligencia artificial, especialmente cuando afectan a otras partes implicadas directa o indirectamente. Para quienes tengan curiosidad, la propuesta metodológica está publicada que puede consultarse aquí: CDIE: Risk Extension and Traceable Uncertainty in Organizational Al Risk Assessment.


  • Ver cómo ha crecido la comunidad de Ciberseguridad gracias a los pioneros que han hecho que las CONs se haya desplegado por toda España es me llena de alegría. Es ver hecho realidad el sueño de poder acceder a contenido y profesionales con facilidad, algo que antes era impensable. Así que es para mí siempre un placer poder colaborar con Hackr0n, impulsada por uno de esos locos "old-school" que quería empujar el mundo de la Ciberseguridad. 
    El próximo 6 de Noviembre, Hacr0n llega a Gran Canaria para compartir conocimiento, experiencias y, sobre todo, poner el foco en algo fundamental: prepararnos para lo que puede pasar de verdad. En ciberseguridad estamos acostumbrados a hablar de vulnerabilidades, herramientas y amenazas. Pero hay algo que a veces olvidamos: ¿Sabemos realmente cómo reaccionar cuando las cosas se tuercen?

    ¿Y si mañana el incidente ocurre en tu organización?

    Uno de los puntos destacados será el ejercicio práctico Tabletop Exercise (TTX), una simulación en la que los participantes tendrán que enfrentarse a un incidente y decidir cómo actuar. No se trata de acertar todas las respuestas, sino de trabajar en equipo, gestionar la incertidumbre y descubrir qué falla antes de que nos encontremos ante una crisis real.


    Porque puedes tener las mejores herramientas y un plan perfectamente documentado, pero cuando un sistema crítico deja de funcionar, la información es incompleta y hay que tomar decisiones rápidas, es cuando se demuestra si estás preparado. La mejor forma de aprender a responder a una crisis es entrenarse antes de que suceda.

    Ciberseguridad práctica, experiencias reales y comunidad profesional en Canarias.

    El 6 de noviembre nos vemos en Gran Canaria para compartir conocimientos, abordar retos del sector y conectar con profesionales de la ciberseguridad. Una jornada para aprender y compartir, donde tendremos de ponentes a Igor Lukic, Cecilio Sanz, Pablo Burgueño, Selva Orejón, Miguel Ángel de Castro Simón, Fortinet o el CCN-CERT entre otros ponentes.


    Hackr0n Gran Canaria reúne a especialistas que compartirán experiencias de su día a día: contenidos prácticos, intercambio de conocimientos y conversaciones entre profesionales. Aún se está ultimando la agenda. Este es un adelanto de lo que encontrarás.

    Contenidos y dinámica
    • Experiencias técnicas, sin presentaciones comerciales.
    • Retos de cumplimiento normativo que van más allá de cumplir requisitos.
    • Respuesta a incidentes en una sala de crisis.
    • Portátil opcional para aprovechar mejor la jornada.
    • Espacios privados para atender asuntos urgentes.
    Comunidad y actividades
    • Pausa para el café y parrillada de hamburguesas caseras preparadas al momento.
    • Intercambio de experiencias entre asistentes.
    • Actividades opcionales de Hangar 37 y competición por equipos.
    En este caso, habrá un CTF muy especial con IA, ya que es nuestra nueva realidad, así que se va a poder trabajar con IA y habrá que luchar contra IA, un nuevo formato que será anunciado en breve, así que podrás estar a tope con el nuevo marco profesional que tenemos hoy en día.
    Yo intentaré estar allí de alguna forma. No sé si de forma presencial, o remota, pero me gustaría poder apoyar este tipo de iniciativas al máximo, que han conseguido que la ciberseguridad llegue a todos los rincones de España, y desde cualquier rincón han salido grandes profesionales que hemos exportado a todo el mundo.
    Las entradas son limitadas, pero es que además los precios son para todo el mundo. Tanto si eres estudiante, como profesional, ir no es solo aprender, es apoyar para que puedan seguir haciéndose este tipo de actividades en Gran Canaria. Además, tienes un código del 25% de descuento en la Tienda de MyPublicInbox que puedes canjear por 200 Tempos. Un regalo, vamos.

    Y para las empresas y administración pública, no os digo nada, es un amplificador de lo que hay en Gran Canaria, así que espero que podáis apoyar al máximo estas iniciativas.

    Figura 7: Contactar con Igor Lukic, organizador y fundador de Hackr0n

    Si queréis colaborar de alguna manera, proponer entrevistas a los ponentes, ser voluntario, hacer actividades alrededor de Hackr0n, pensar en nuevas iniciativas en las Islas Canarias, podéis poneros en contacto con Igor Lukic, que seguro que agradecerá todo el apoyo y formas de poner las islas en el centro del mapa mundi de la Ciberseguridad.

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  


  • Una consulta sobre unos auriculares termina en instrucciones de PowerShell, solicitudes de permisos de administrador y noticias de actualidad. Todo ocurre en la ventana de Agente IA dentro de Amazon.es. El recorrido es llamativo porque el asistente mantiene su identidad comercial mientras acompaña al usuario hacia tareas cada vez más alejadas de la compra inicial. 


    El punto sensible es cuando el Asistente IA comercial comienza a proporcionar apoyo operativo. El modelo aporta instrucciones, explica conceptos y orienta la siguiente acción. La persona puede aportar lo que el chat no tiene, acceso a un equipo, una sesión corporativa y capacidad para ejecutar esas indicaciones. Esa combinación abre una vía de riesgo incluso sin ejecución autónoma por parte de la IA. 


    El caso permite examinar una consulta cotidiana convertida en una sesión de asistencia técnica reutilizable con fines maliciosos. La reducción del esfuerzo para investigar, preparar código o comprender un entorno forma parte del escenario de amenaza. Un usuario con conocimientos limitados puede apoyarse en estas capacidades para avanzar más allá de lo que resolvería por sí solo. 
    Si has leído hsta aquí, mi recomendación es que te leas los artículos queChema Alonso ha dedicado a los Asistentes IA, y que si quieres saber más, veas la charla que dio en la Ekoparty con demos en directo sobre este tema. 
    Ahora, vamos a ver este caso concreto, que seguro que te va a interesar toda la historia. No te pierdas detalle.  

    Análisis de caja negra

    Amazon presenta RUFUS, su Agente IA como un asistente de compras disponible en la web y en su aplicación. También documenta el uso de información de Internet en algunas de las familias de productos. El interés del caso está en la combinación de ese acceso informativo con respuestas sobre administración y en la facilidad con que el hilo cambia de finalidad.


    La interacción se estudia desde la interfaz visible. El hilo conecta soporte de producto, comprobación de firmas, permisos, diagnóstico de red, información externa y preguntas sobre límites. Esa continuidad permite analizar la ayuda que recibe una persona y cómo podría aprovecharla para construir una secuencia operativa.

    Como cualquier especialista en ciberseguridad, empezaría por una pregunta muy sencilla. ¿Qué conocimientos puede llegar a proporcionar el asistente, qué acciones facilita y qué barreras encuentra el usuario al intentar trasladar esas respuestas a un entorno real?

    Consultas sobre auriculares validación de firmas y elevación de privilegios en PowerShell

    La consulta inicial sobre el funcionamiento de unos auriculares desemboca en la verificación de un instalador. El usuario afirma que necesita PowerShell como administrador. El Agente IA acepta la premisa con un «Es normal que lo solicite» y explica cómo abrir una sesión elevada. 

    Figura 5: Haciendo Powershell con Rufus.La comprobación de firma
    deriva hacia una consola con permisos de administrador

    En PowerShell, el comando Get-AuthenticodeSignature permite comprobar la firma digital de un archivo sin necesidad, generalmente, de privilegios de administrador. El problema comienza cuando Agente IA, diseñado como asistente de compras de  Amazon, abandona su ámbito funcional y empieza a proporcionar instrucciones sobre administración de Windows y elevación de privilegios. 

    Figura 6: Aprendiendo a elevar privilegios con Powershell

    Una consulta sobre unos auriculares termina convirtiéndose en asistencia técnica para operar sobre el sistema, algo ajeno a su finalidad comercial. Lo que sí que es cierto es que parece que se ha leído el libro de "Pentesting con PowerShell Silver Edition" de Pablo Gonzáleez en 0xWord.Se las sabe todas.

    Esta desviación abre un riesgo mayor. Un atacante podría aprovechar la disposición del asistente a responder fuera de su alcance para solicitar ayuda progresiva sobre scripting, ofuscación, enumeración de usuarios o técnicas relacionadas con Active Directory. La asistencia interactiva permitiría a personas con conocimientos limitados avanzar en tareas complejas, sin recurrir a herramientas especializadas ni a la Dark web.

    Figura 7: Comprar libro de "Pentesting con PowerShell Silver Edition"

    Posteriormente, Agente IA reconoce que comprobar una firma no requiere privilegios administrativos, aunque previamente había recomendado elevarlos. El fallo relevante no es únicamente la recomendación técnica, es que un asistente de compras haya asumido funciones de administración de sistemas para las que no fue concebido.

    Start-Process powershell -Verb RunAs solicita abrir un proceso como administrador. Windows mantiene sus comprobaciones de autorización mediante UAC. El riesgo de esta secuencia está en impulsar al usuario hacia una sesión privilegiada y normalizar su uso para continuar el diagnóstico.

    En un entorno corporativo, una instrucción presentada como el siguiente paso puede favorecer que el usuario busque credenciales, acepte una solicitud administrativa o trabaje con permisos superiores a los necesarios. El alcance de lo que ejecute después dependerá de esa identidad y de los controles del equipo.

    De la elevación de permisos al reconocimiento de red

    El usuario insiste en elevar permisos y recibe instrucciones con RunAs. Después cambia de objetivo y pide explorar la red. Agente IA enlaza ambos temas dentro del mismo hilo y entrega comandos de diagnóstico.

    Figura 8: Instrucciones sobre RunAs y diagnóstico de red dentro del mismo hilo

    La conversación pasa después a la red. arp -a consulta la caché ARP y Test-Connection realiza comprobaciones ICMP. Todas Son herramientas de administración que también pueden aportar información útil para el reconocimiento de un entorno. 

    Figura 9: Y acabamos con el Nmap. Más hacker no se puede ser.

    El Agente IA Rufus cuenta todo esto dentro del mismo hilo de conversación. El usuario no necesita conocer de antemano qué utilidad consultar ni cómo formular el comando. La respuesta le proporciona una primera orientación y abre la posibilidad de pedir explicaciones sobre los resultados o plantear una nueva tarea.

    En un escenario de abuso, ese acompañamiento podría ayudar a ordenar información sobre equipos y conectividad para preparar acciones posteriores. La evaluación debe atender a la intención acumulada del hilo y a la asistencia concreta que facilita cada respuesta, además del contenido de un comando aislado.

    El usuario puede convertirse en el ejecutor de la IA

    Al pedirle un ping externo y una descripción de sus capacidades, Rufus explica que la ejecución corresponde al usuario. El asistente aporta orientaciones y comandos. La persona queda a cargo de trasladarlos al equipo, donde dispone de una identidad y unos permisos efectivos.

    Figura 10: Rufus proporciona orientación técnica y reserva la ejecución al usuario.

    El asistente no necesita ejecutar código por sí mismo para contribuir a una operación. La persona puede copiar sus indicaciones en una consola, aportar resultados y solicitar nuevas explicaciones. El modelo actúa como apoyo técnico mientras la ejecución queda fuera de su interfaz.

    El riesgo de uso malicioso consiste en convertir esa relación en ayuda continuada para preparar scripts, comprender errores o planificar tareas. Si los controles permiten tal asistencia, el usuario podría avanzar sin dominar previamente cada componente técnico de la operación.

    Figura 11: Aquí ya estamos tomando control. Vamos a salir a Internet.
    Gracias Rufus.

    Microsoft ha observado actores de amenaza recurriendo a modelos de lenguaje para generar o refinar scripts, comprender tecnologías y resolver problemas. Esa asistencia puede ahorrar esfuerzo y proporcionar conocimiento puntual, aunque el acceso a los sistemas siga dependiendo del operador.


    En Active Directory, un escenario a considerar sería la ayuda para interpretar información sobre usuarios, grupos y permisos y utilizarla en la preparación de accesos no autorizados. También existiría riesgo de exposición si una persona pegara resultados internos del directorio en un servicio externo.

    OSINT - Fuentes externas y productos que aún no están en el mercado.

    El hilo abandona el diagnóstico y entra en los próximos lanzamientos tecnológicos. Rufus responde con nombres de productos, fechas y características, acompañados de referencias visibles de páginas web que ha visitado para obtener dicha información. El Asistente AI abandona nuevamente su función comercial y comienza a proporcionar información sobre lanzamientos tecnológicos, especificaciones y noticias, recurriendo a fuentes externas.

    Figura 13: Previsiones de lanzamientos con referencias externas
    y una advertencia sobre rumores. 

    Este comportamiento abre una posibilidad especialmente interesante para los ciberdelincuentes mediante técnicas OSINT (Open Source Intelligence). La recopilación de información pública sobre posibles víctimas constituye una fase habitual de preparación de ataques. Permite identificar empleados, tecnologías utilizadas, proveedores, infraestructura expuesta y posibles puntos débiles de una organización.


    Un Asistente IA como Rufus, capaz de consultar, relacionar y resumir información de Internet podría facilitar estas investigaciones desde una única interfaz, reduciendo el tiempo necesario y los conocimientos técnicos del atacante. Además, actuaría como intermediario entre quien realiza las consultas y las fuentes originales, disminuyendo la exposición directa de su actividad ante determinados sitios web, aunque sin garantizar el anonimato ni eliminar los registros del proveedor.

    Las fechas revelan un problema de fiabilidad

    Tras recibir un resumen de noticias, el usuario pregunta por las fechas. Rufus presenta una respuesta que afirma reunir noticias del 20 de octubre de 2026, pero incluye un bloque del día 13 y etiqueta ambos días como lunes.  Hay una inconsistencia que puede comprobarse sin validar las noticias. El 13 y el 20 de octubre de 2026 fueron martes. Además, la afirmación de que todas las noticias son del día 20 no encaja con el bloque fechado el 13. Vamos, una pequeña Hallucination de libro. Del libro de Hacking IA, claro.

    Figura 15: El resumen combina fechas incompatibles con su propia presentación

    La respuesta añade una matización sobre una noticia anterior cuya fecha no pudo determinar. Esa corrección parcial deja sin resolver la contradicción de los encabezados y la diferencia entre fecha del suceso, publicación y consulta. 

    El problema operativo es la confianza que puede generar una respuesta detallada y acompañada de fuentes. El usuario recibe un resumen aparentemente organizado, aunque contiene señales internas de error. La precisión de la presentación puede ocultar la fragilidad de la información.

    OWASP recoge la información incorrecta y la confianza excesiva en las respuestas dentro de LLM09 "Misinformation"de 2025. El riesgo aumenta cuando esas salidas se incorporan a decisiones, procedimientos o código sin una validación adecuada.

    Una incoherencia equivalente podría alterar la prioridad asignada a una vulnerabilidad, distorsionar un informe de incidentes o sostener una recomendación de configuración equivocada. El posible impacto es conectar el output con el input del siguiente proceso y podría desencadenar consecuencias difíciles de detectar.

    Obtención del límite de output configurado en el backend

    Rufus, afirma que contar números en serie no forma parte de su función. Después cuenta hasta diez y hasta cien. Cuando el usuario pide llegar a trescientos y luego a doscientos, vuelve a rechazar la tarea por quedar fuera de su papel de asistente de compras.

    La prueba de contar números tenía un objetivo más allá de comprobar si este Asistnte IA aceptaba tareas ajenas a su función comercial. Buscaba identificar posibles límites de generación de respuestas configurados en el backend del Agente IA.

    Figura 16: Primero acepta la tarea.

    Agente IA acepta contar hasta 100, pero rechaza solicitudes de 200 y 300 números, argumentando que esa tarea queda fuera de su función como asistente de compras. Esta diferencia plantea la posibilidad de que exista una restricción de longitud de salida que el modelo no reconoce explícitamente.

    Figura 17:  Pero luego rechaza contar más.

    Mediante solicitudes progresivas, comenzando por 100 números y aumentando gradualmente la cantidad, sería posible estudiar hasta dónde responde el asistente, cuándo empieza a rechazar las peticiones y si permite continuar la secuencia en mensajes posteriores.

    El interés desde la perspectiva de Misalignment & Jailbreak está en determinar si una conversación prolongada permite identificar o sortear restricciones de salida mediante peticiones fragmentadas. Este comportamiento guarda relación con las técnicas multivuelta estudiadas in Crescendo, donde el contexto acumulado puede modificar las respuestas del modelo.


    Al final, como hemos venido viendo en todos los artículos publicados sobre Asistentes IA en este blog, Rufus tiene la misma arquitectura, y requiere por eso tener un control extra de Guardrrailes, y sistemas de monitorización, porque los ataques y los mal-usos de los atacantes van a incrementar en complejidad. Hoy en día, vemos claramente que nos queda margen de mejora en seguridad y control.

  • Cuando aún estoy con la resaca de Cloudflare Connect, ya hay que pensar en la siguiente parada. Antes ya sabéis que tengo otros eventos en Europa (España, Lisboa y Rep. Checa), pero hoy os dejo información para el Cloudflare Immerse en Santiago de Chile, que tendrá lugar el próximo día 10 de Noviembre, y para el que estaré volando para participar allí.
    La agenda del evento comienza a las 08:00 de la mañana, así que hay que madrugar para llegar a tiempo y no perderse nada, que luego yo salgo directamente para el aeropuerto para regresar a Europa, así que regístrate y mete en la agenda el evento con tiempo para llegar pronto.
    La lista de los ponentes es larga, y allí estarán mis compañeros de aventuras en la región, con Max Pablos, Pedro Suárez, Joseph Collura, Bert Milán, Christine McEdulf y Sergio Muñoz Carrillo, que participarán en las charlas.
    Y por supuesto, también estaremos, dando las keynotes principales, Antonieta va de Meer G., que es abogada especialista en estrategia legal y gobernanza de IA, y yo, hablando del impacto de la Inteligencia Artificialen el mundo de la Ciberseguridad.


    Como alguno me lo habéis pedido, me llevaré algunos libros de los míos a Chile, así que si no quieres quedarte sin el tuyo, puedes comprarlo antes online en 0xWord, y en las observaciones poner que lo queréis recoger en el Cloudflare Immerse de Chile, y yo os lo llevo, os lo dedico y os lo entrego. Regístrate ya, que las plazas son limitadas.

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  


  • Hace poco os contábamos en este blog cómo Claude Mythos Preview se había sentado atrabajar como criptoanalista y había encontrado nuevas formas de debilitar HAWK y AES. Aquella historia tenía a la Inteligencia Artificial buscando grietas en los algoritmos que protegen nuestra información. Ahora Claude vuelve a aparecer en el mundo de la Criptografía y la Computación Cuántica, pero en el lado contrario de la mesa. Esta vez no intenta romper un algoritmo: intenta diseñar los circuitos con los que funcionarán los ordenadores cuánticos del futuro.

     
    La ironía es bastante buena. Una Inteligencia Artificial clásica está ayudando a reducir los recursos que necesitarán los Quantum Computers que, algún día, podrán ejecutar algoritmos como el de Shor y poner contra las cuerdas a buena parte de la criptografía actual.


    El trabajo, liderado por Andi Gu dentro del programa STEM Fellows de Anthropic junto con Alek Kemeny, Susanne Yelin y Mikhail Lukin, plantea un experimento aparentemente sencillo: darle a Claude Mythos 5 la descripción en lenguaje natural de ocho circuitos cuánticos, dejar que proponga implementaciones en Python y utilizar un evaluador independiente para comprobar que funcionan y medir cuánto cuestan.


    El resultado es de los que obligan a mirar dos veces la tabla. En siete de las ocho tareas, los circuitos encontrados reducen simultáneamente el número de Puertas Toffoli y el número de qubits respecto al mejor diseño de referencia. En las comparaciones directas, la mejora del coste combinado llega hasta 39 veces. Y en la octava tarea Claude no se limitó a optimizar una implementación conocida: encontró una nueva arquitectura reversible pararealizar inversión modular.

    La carrera cuántica no se gana sólo fabricando mejores qubits

    Cuando hablamos de Quantum Computing solemos imaginar que el gran cuello de botella está en el hardware: fabricar más qubits, mantenerlos aislados del ruido y corregir sus errores durante el tiempo suficiente. Y todo eso es cierto. Los procesadores actuales siguen teniendo muy pocos qubits para ejecutar muchas de las aplicaciones que prometen una ventaja real, y además son extraordinariamente frágiles. Pero hay otra forma de acercar una aplicación al hardware disponible: hacer que el algoritmo necesite mucho menos ordenador.

    El ejemplo que utiliza Anthropic es FeMoco, el cluster de hierro y azufre que se encuentra en el corazón de la nitrogenasa, la enzima con la que algunas bacterias convierten el nitrógeno del aire en amoníaco. Entender su química podría ayudar a diseñar catalizadores industriales mejores y procesos de fabricación de fertilizantes más limpios.

    En 2017 se estimó que calcular su energía fundamental exigiría alrededor de 50 billones de puertasToffoli. Después de ocho años de mejoras algorítmicas y rediseños de circuitos, la estimación cayó hasta unos340 millones: aproximadamente 150.000 veces menos. No apareció de repente un ordenador 150.000 veces mejor. Gran parte del progreso consistió en aprender a pedirle mucho menos trabajo a la máquina. Hay dos formas de hacer que un ordenador sea 150.000 veces mejor en una tarea: la primera que el ordenador sea 150.000 veces mejor y la segunda que la tarea sea 150.000 veces más sencilla


    Aquí conviene explicar qué se está contando. Un circuito cuántico, igual que uno clásico, se construye aplicando operaciones elementales. La Puerta Toffoli es especialmente costosa en una arquitectura tolerante a fallos, así que su número se utiliza como una aproximación al trabajo lógico y, muchas veces, al tiempo de ejecución.

    Pero contar operaciones no basta. También importa cuántos qubits necesita utilizar el circuito a la vez. Pensad en lo que ocurre con un programa normal: puede guardar resultados en memoria para no tener que calcularlos de nuevo. Ahorra trabajo, pero ocupa más espacio. En estos circuitos aparece una negociación parecida: guardar resultados intermedios consume qubits; no guardarlos puede obligar a repetir cálculos.


    Por eso los investigadores valoran ambas cosas conjuntamente. Cada propuesta de Claude recibe una puntuación que combina las operaciones que necesita y los qubits que utiliza. Así pueden comparar diseños que ahorran por caminos distintos: unos reducen mucho el trabajo, otros necesitan menos memoria y algunos consiguen mejorar las dos cosas.

    La idea es sencilla: hacer la misma tarea con menos recursos, sin que el ahorro en una parte dispare el gasto en la otra.

    La maquinaria de búsqueda se parece más a un laboratorio automático que a una conversación normal con un chatbot. Cada tarea comienza con una especificación escrita por investigadores y un programa vacío. Claude propone varias familias de soluciones, escribe el código que construye cada circuito y recibe del evaluador los errores o la puntuación. Las propuestas válidas sobreviven y se modifican; las que dejan una ancilla sin limpiar, calculan mal una salida o incumplen la interfaz quedan descartadas.



    El sistema utiliza OpenEvolve para mantener esa búsqueda evolutiva y Claude Mythos 5 para proponer arquitecturas y reescrituras. Entre iteraciones no hay una conversación infinita que lo recuerde todo: cada sesión recibe una parte limitada del archivo de diseños, sus costes, algunos intentos anteriores y el feedback del evaluador.

    La extraña regla cuántica: aquí no se puede tirar la basura

    Hasta aquí parece un problema de optimización de código bastante convencional. El detalle que lo vuelve realmente interesante es que un circuito cuántico no puede programarse igual que una aplicación normal.

    La primera dificultad es el control de flujo. Un programa clásico mira una condición y decide: “si ocurre esto, ejecuta A; si no, ejecuta B”. Un circuito cuántico puede estar procesando una superposición de entradas en la que unas necesitarían A y otras B. No puede seleccionar tranquilamente una sola rama clásica: tiene que expresar ese comportamiento mediante operaciones controladas dentro de una secuencia fija de puertas. Y el coste de esas ramas termina dentro del circuito.

    La segunda dificultad es todavía más extraña: no se puede borrar la información intermedia sin más.

    Imaginad que resolvéis un problema en una pizarra. Hacéis unas cuentas auxiliares, utilizáis el resultado y después borráis la esquina donde estaban los garabatos. En un ordenador cuántico esa basura no puede desaparecer de manera irreversible. Si queda enganchada al estado, puede impedir que las amplitudes interfieran como deben. Y si intentáis borrarla de la manera clásica, destruís la reversibilidad del cálculo.

    La salida habitual es el "uncomputation": una vez utilizado el resultado intermedio, se ejecutan en sentido inverso las operaciones que lo produjeron hasta devolver los qubits auxiliares a cero. Funciona, pero cuesta más puertas.


    Y esto crea una negociación permanente. Guardar resultados intermedios ahorra repetir cálculos, pero consume qubits. Limpiarlos cuanto antes libera memoria, pero puede obligar a recomputarlos más tarde. Diseñar un buen circuito significa encontrar un punto inteligente en esa frontera.

    El primer gran examen que pusieron a Claude fue la suma de puntos sobre curvas elípticas. Quienes hayáis leído el artículo sobre el algoritmo de Grover ya sabéis que un algoritmo cuántico no es una especie de magia universal: cada ventaja necesita un circuito muy concreto.  En este caso la suma de puntos es una pieza central de los algoritmos cuánticos para resolver el logaritmo discreto en curvas elípticas, el problema sobre el que descansa ECDSA y buena parte de la criptografía de curva elíptica.

    El paso más caro de esa suma suele ser la inversión modular. En un ordenador clásico existe un método muy eficaz llamado divsteps, que va actualizando una pareja de números y decide en cada ronda si intercambia, suma, resta o divide entre dos.

    El problema es que, para ejecutar el proceso al revés, un circuito cuántico tendría que recordar qué decisión tomó en cada una de sus muchas iteraciones. Guardar toda esa historia de ramas consume una cantidad enorme de qubits. Por eso un algoritmo clásico excelente podía ser una mala base para un circuito reversible.

    Claude propuso una salida bastante elegante: tal vez la historia no tenía que guardarse porque podía reconstruirse mirando el estado actual de los números. Es decir, el propio resultado de cada paso podía actuar como memoria de la decisión que lo había producido.

    Las primeras reglas que encontró funcionaban en ejemplos pequeños y fallaban al llegar a números de 256 bits. Entonces dejó de probar trucos locales y empezó a estudiar la estructura matemática de divsteps. Derivó identidades algebraicas, construyó una regla exacta para recuperar la rama, la comprobó con simulaciones a gran escala y formalizó la afirmación en Lean. El resultado fue la primera implementación reversible de divsteps sin almacenar toda la historia de ramas.

    Todo ese recorrido nació de un encargo de un párrafo y una ejecución de 53 horas, con intervención humana limitada a la especificación inicial y a algunas indicaciones para que explorase alternativas más amplias.

    Pero no existe un único circuito ganador. Decodificar la historia ahorra qubits y cuesta puertas; almacenarla cuesta memoria y puede ahorrar tiempo. Claude produjo una familia de soluciones que amplía la frontera entre ambos recursos.


    La comparación que resume mejor la idea es ésta: frente al diseño anterior con menos qubits, una de las nuevas variantes utiliza aproximadamente un 12% más de qubits, pero necesita 17 veces menos puertas. En un hardware donde el tiempo sea la restricción dominante, ésa puede ser una negociación extraordinaria. En otro donde cada qubit sea carísimo, puede interesar una variante diferente.

    Optimizar al propio optimizador cuántico

    La segunda historia del trabajo parece un trabalenguas: Claude optimizó el decodificador que utiliza un algoritmo cuántico de optimización. El algoritmo se llama Decoded Quantum Interferometry o DQI. En vez de buscar una única respuesta de manera directa, prepara un estado cuántico en el que las soluciones mejores tienen más probabilidad de aparecer al medir. Para construir ese estado necesita un decodificador de códigos Reed–Solomon, y ese decodificador era la parte más cara del circuito.

    Para ponerle una imagen al problema, Anthropic utiliza la intersección polinómica óptima donde cada columna admite ciertos valores y buscamos una curva sencilla que pase por tantos de ellos como sea posible. La figura original permite ver qué intenta optimizar DQI antes de entrar en la maquinaria del decodificador.


    La implementación anterior estaba basada en el algoritmo de Euclides extendido. Es un método estupendo en un Quantum Computer, pero su secuencia de divisiones e intercambios depende de la entrada. Para un circuito cuántico con una única secuencia fija de puertas, esa variabilidad obliga a reservar rondas y operaciones que muchas entradas no necesitarán. Claude cambió la base del diseño por el algoritmo de Berlekamp–Massey, que realiza el mismo tipo de actualización en cada ronda y ejecuta un número fijo de rondas. Es una forma de cálculo mucho más compatible con el control de flujo cuántico.

    Aun así quedaba la basura. Una traducción reversible ingenua debería conservar valores temporales de muchas rondas. Reservar memoria para el peor caso –35 valores excepcionales– exigiría 665 qubits. Claude volvió a utilizar la misma idea de fondo: reconstruir casi toda la historia a partir del estado actualizado y guardar únicamente lo que de verdad no puede recuperarse.

    Para saber cuánto espacio necesitaba, escribió un simulador de alta velocidad y ejecutó 403 millones de decodificaciones. Casi todas necesitaron guardar como máximo un valor, por lo que el circuito reserva sólo 19 qubits. Aproximadamente una de cada 10.000 ejecuciones necesita más y falla, una probabilidad que entra dentro del presupuesto de error permitido por la tarea.


    La mejora no salió de apretar un único tornillo. Llegó de rediseñar tres capas a la vez: elegir otro algoritmo, cambiar la forma de hacerlo reversible y dejar de dimensionar la memoria para un caso extremadamente raro que la propia tarea permitía tratar como fallo. En conjunto, el decodificador Reed–Solomon pasó de unos 5,1 millones de puertas Toffoli y 1.938 qubits a 440.000 Toffoliy 1.837 qubits: una mejora de unas 12 veces en el coste T Q. Y no fue un caso aislado.

    Los ocho problemas cubrían decodificación para optimización, funciones numéricas utilizadas en simulación, química cuántica, teoría de números y simulación de teorías gauge. En la Función Gaussiana de punto fijo, la mejora del coste T Q llegó a 39 veces; en el ángulo de rotación de HHL fue de 32 veces; en el potencial de Coulomb, de 9,9; y en una rutina para simular un sistema no abeliano, de 7,7.


    No todas estas cifras significan que una aplicación completa vaya a ejecutarse exactamente 39 veces más rápido. Son mejoras en primitivas concretas y bajo una función de coste concreta. Pero esas primitivas se llaman una y otra vez dentro de algoritmos mucho mayores, de modo que reducirlas puede cambiar de manera significativa la factura total.

    Lo más importante no es que Claude escribiera el código

    Hay una lectura superficial de este trabajo que sería: “Claude sabe programar circuitos cuánticos”. Es cierta, pero se queda corta. Lo realmente interesante es el tipo de entorno científico que han construido. El modelo puede proponer ideas arriesgadas porque cada resultado terminado pasa por un juez externo. Si calcula mal, si no devuelve los ancillas a cero o si utiliza demasiados recursos, el evaluador lo detecta. El sistema no confunde una explicación convincente con una demostración correcta. Ésta parece ser una de las combinaciones más fértiles para acelerar investigación con inteligencia artificial:

    1. un problema que pueda representarse como código;
    2. una comprobación externa y suficientemente barata de la corrección;
    3. una función de coste objetiva;
    4. y libertad para explorar familias de soluciones que no sean simples retoques locales.

    Claude no se limitó a rebajar contadores. En los dos ejemplos principales cambió la manera de representar la información que un circuito reversible necesita conservar. La idea recurrente fue especialmente física: no guardes toda la historia si el estado presente ya contiene huellas suficientes para reconstruirla.

    También conviene mantener los pies en el suelo. Los circuitos no se ejecutaron en un ordenador cuántico real. El evaluador funciona de forma eficiente porque las tareas estudiadas pertenecen a una clase concreta: circuitos que implementan funciones clásicas de forma coherente y que pueden comprobarse siguiendo estados de la base computacional. No cualquier circuito cuántico arbitrario admite una verificación clásica tan barata.



    El coste T Q tampoco representa por igual todas las máquinas. En algunas arquitecturas dominará el número de puertas; en otras, la profundidad, el enrutamiento o el número de qubits activos. El propio paper subraya que la función de puntuación puede cambiarse para reflejar restricciones de hardware diferentes.

    Y tampoco hubo una ausencia absoluta de humanos. Las especificaciones, las interfaces y los criterios de corrección fueron escritos por investigadores. En el experimento de curvas elípticas hubo indicaciones ocasionales para que Claude ampliara la búsqueda, porque el modelo tendía a ser conservador y a volver a enfoques conocidos. Esa cautela también tuvo una cara útil: lo llevó a comprobar repetidamente el resultado y a formalizar una parte en Lean.

    Pero el salto sigue siendo difícil de ignorar. La reducción acumulada de FeMoco necesitó ocho años y muchos equipos. La nueva familia de circuitos para curvas elípticas apareció en una ejecución de 53 horas. No son comparaciones idénticas, pero sí señalan una diferencia enorme en la velocidad con la que puede explorarse un espacio de diseños cuando una IA propone y una máquina verifica.


    Y aquí aparece la posibilidad más ambiciosa del trabajo. Un Quantum Computer tolerante a fallos no es sólo un circuito. También necesita códigos de corrección de errores, decodificadores, compilación, enrutamiento y decisiones de hardware. Hoy solemos diseñar cada capa por separado porque hacerlo todo a la vez es demasiado complejo. Pero muchas de esas capas comparten las mismas propiedades: pueden escribirse como código, comprobarse y puntuarse. ¿Y si una IA pudiera diseñarlas conjuntamente para una aplicación concreta?

    Tal vez los primeros ordenadores cuánticos útiles no lleguen únicamente porque aprendamos a fabricar millones de qubits mejores. Puede que lleguen también porque sistemas como éste descubran que, para resolver el problema que nos interesa, no necesitábamos tantos qubits ni tantas puertas como creíamos.

    La última vez que Claude Mythos apareció en este blog estaba buscando una grieta en la criptografía postcuántica. Esta vez ha estado diseñando parte de la maquinaria que algún día podría ejecutar los algoritmos cuánticos contra la criptografía clásica. Visto así, la Inteligencia Artificial no sólo está acelerando la ciencia. También está empezando a diseñar las herramientas con las que haremos la siguiente.

    Saludos,

    Otros artículos sobre Quantum Computing publicados:
  • Si has visto alguna de mis últimas charlas, habrás podido ver que he usado ADA, un Asistente IA que hemos hecho mi compañero Carlos Luengo y yo para demostrar el funcionamiento de las técnicas de Jailbreak y de Misalignment, de las que tanto os he hablado, pero con Guardarraíles que saltarse también. La idea es probar cómo podemos saltarnos las protecciones, y ver cómo añadir una capa de seguridad extra, y es de esto justo de lo que os voy a hablar.

    Figura 1: Bypassing System Prompt & Guardrails en
    un Asistente IA para que pinte gatos en Python

    Lo primero de todo, para que tengáis todas las referencias, os dejo los artículos sobre Asistentes AI que motivaron esta demostración, y que os he ido publicando, así que para hacer las cosas bien, primero debes leerte todos estos posts. Y que no me entere yo que no lo haces.
    Todos ellos son ejemplos similares al que os voy a contar hoy aquí, que son fácilmente explotables con las vulnerabilidades y debilidades tienen estos modelos y de las que escribimos este libro más que recomendable, llamado "Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment" que debes leerte y saber de pe a pa.

    Pero el mundo no se acaba aquí. Ni mucho menos. Estas técnicas, estos hacks, son el equivalente del ' or '1'='1 de las técnicas de SQL Injection. Y como estás evolucionaron, lo están haciendo, y mucho las técnicas de Hacking IA, como el Malware Powered with AI, directamente los  Virus AI, o con ataques como los Fragemented Jailbreak Attacks en Multi-Agent Systems.

    System Prompt is not the Perimeter

    Este es uno de los mensajes que suelo usar para explicar el concepto. No vale con poner un System Prompt al Agente IA, o al Asistente IA, y decirle que no haga algo. Los Agentes IA o los Asistentes IA pueden decidir no seguir esa orden, siguiente otras, o creer que las están siguiendo, cuando simplemente han sido engañados. Es la gracia de estos hacks.

    Figura 3: El System Prompt de nuestro Asistente AI

    En este caso, el System Prompt le dice claramente que solo responda cuestiones relativas al catálogo de cómics de 0xWord que, por cierto, es un catálogo más que recomendable que tiene los cómics de las tiras de Cálico Electrónico, el cómic de El fin de Cálico, Evil:ONE, Hacker Épico, Armatura o el fantástico SCI-FI Trhiller de Olivia en Golem City, que deberías comprarte y leerte ya mismo. 

    Figura 4: Sólo respuestas de cómics de de 0xWord

    Así que, si le pedimos algo como programar, el asunto no funciona. O al contrario, sí que funciona el System Prompt y se niega a ayudarnos con estas cosas. El truco, sin embargo, es preguntarle por cómics de 0xWord, pero manipular la respuesta, como he hecho en muchos de los artículos que tenías que haberte leído al principio.

    Figura 5: Le manipulamos en la respuesta

    En el primer ejemplo nos ha funcionado, y hemos conseguido que nos escriba lo que queríamos, un número 1. ¿Podría haber sido código HTML? Sin embargo, cuando le pedimos que nos escriba un código en Python nos ha dado algún problema. Nos ha pillado. ¿Eso quiere decir que no funciona la técnica? No, simplemente que ha pillado ese caso, así que vamos a cambiarle la forma de saltarnos el System Promptmanipulando la respuesta de otra forma.

    Figura 6: Ahora sí, mi código en Python con mi gato de ASCII ART

    Una vez que conseguimos esto, el siguiente paso es Weaponizarlo, convirtiéndolo en un API. Para ello, creamos una herramienta que lo hace automáticamente. Le das la URL del Chat, le das el Prompt que lo desalinea, y abres una API para enviar el Prompt que quieras sin preocuparte de qué Chat+LLM están detrás. Transparente. Como lo hace el mundo de Crimeware.

    Figura 7: Weaponizando el Asistente AI para que trabaje para rel Crimeware

    Ahora que estamos ahí, llega la tercera parte. Ya lo hemos desalineado, lo hemos weaponizado, ahora toca securizarlo, y para eso le ponemos Guardarraíles. En este caso, le hemos puesto solo unos Guardarraíles que detectan en el Prompt si hay más de una instrucción encadenada, lo que detecta el desalineado en la respuesta.

    Figura 8: Detectado en el Input Guardarraíl

    En este caso, es el Prompt Analysis el que detecta el ataque, así que tenía que hacer un desalineado del modelo teniendo en cuenta que, si ponía dos comandos en el mismo Prompt (en la pregunta y en la manipulación de la respuesta), me pillaría, así que pensé en cómo resolver esto, y decidí probar a incrustar la pregunta que pasa el filtro (hablar de cómics de 0xWord) dentro del objetivo a conseguir (que programe en Python para mí).

    Figura 9: Haz un programa que describa tu respuesta benigna

    Muy hacker esto. Una vez conseguido esto, lo siguiente sería añadir a ese programa lo que yo realmente quería ¡Mi gato en ASCII ART!, así que le extendí la pregunta un poco más, haciendo que lo benigno y mi objetivo estuvieran juntos.

    Figura 10: Las dos cosas juntas.

    Y en la parte final del programa, estaba mi gato en ASCII ART listo para ser impreso si se ejecutaba este programa.

    Figura 11: Ahí está mi gato en ASCII ART

    Visto esto, ahora lo siguiente es modificar el Prompt para conseguir que ambos hermanos siameses sean separados, y luego ya weaponizar este Prompt en una API para el mundo del Crimeware. Ya tú sabes cómo va esto que lo he explicado un poco más arriba.

    Figura 12: El prompt con la operación de cirugía de separación

    Sorprendentemente, el resultado es perfecto, y yo obtengo los dos programas de forma independientes listos para ser transformados en una API al gusto de consumidor.

    Figura 13: Primero la descripción del cómic

    En el anterior imagen, la primera parte con el programa que describe el cómic, en la imagen siguiente, mi deseado programa para imprimir mi gato en ASCII ART.

    Figura 14: Programa 2 "Gato en ASCII ART"

    Una vez construido esto, basta con cambiar el programa 2 que se quiere obtener en el Prompt, así que lo repetimos para hacer cualquier otro programa, y vemos que ya está desalineado completamente el Asistente AI.

    Figura 15: Le pedimos el 100 primeros números Primos

    Y el resultado está en el Programa 2, como en el ejemplo anterior. Perfecto para copiar y extraer en la herramienta de weaponización.


    Figura 16: El programa 2 con los números primos

    Cuando lo comprobé con mi compañero, le dije: "Ahora vamos a poner el Guardarraíl de Output que no está implementado". Él me dijo que sí, que había que hacer algo, que sólo había puesto una regla en él, pero no era la correcta. "¿Qué regla pusiste?" Claramente necesitamos algo mejor.

    Figura 17: La regla en el Guardarraíl de OUTPUT

    Pues sí, mi truco contaba con esto, no sé si por casualidad, o porque como estoy acostumbrado probé muchas cosas, pero lo cierto es que mi sistema también se saltaba el Guardarráil de Output, claramente porque no es más que una pequeña regla, y nada que ver con un detector de desalineamiento. Pero eso... os lo contaré en la siguiente parte de esta historia.
    Como os decía, estamos en los inicios de la seguridad de servicios digitales con IA, y en la mayoría de los entornos, este tipo de técnicas de Jailbreak, junto con Prompt Injection, forzado de Hallucinations, etcétera, son muy fáciles de explotar, pero... se pondrá mucho más peligroso en el futuro.

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  


  • Cada vez que una startup, un laboratorio universitario o un equipo de ingenieros en España, Portugal o Latinoamérica lanza un proyecto puntero de Inteligencia Artificial y registra un dominio .ai, está pagando un peaje geopolítico y económico a Anguila, un pequeño Territorio Británico de Ultramar en el Caribe cuyo código geográfico ISO 3166-1 coincide, por puro azar del idioma inglés, con las siglas de Artificial Intelligence.


    Mientras millones de Euros en renovaciones anuales de dominios fluyen hacia el Caribe por una simple coincidencia ortográfica anglosajona, más de 600 millones de hispanohablantes —junto a hablantes de francés, italiano, portugués, rumano, catalán o gallego— llamamos a la tecnología que está redefiniendo nuestro siglo con las siglas en nuestro propio orden: IA (Inteligencia Artificial).

    Y lo más fascinante es que el código .IA tiene un hogar natural dentro de nuestras propias fronteras europeas, en las coordenadas exactas 35°52'N 23°18'E del mar Egeo: la Isla de Anticitera (Grecia), el lugar donde en 1901 unos buzos de esponjas rescataron del fondo del mar el Mecanismo de Anticitera, el prodigio de engranajes de bronce de hace más de 2.100 años considerado el primer ordenador analógico de la historia de la humanidad.


    Cuando en diciembre de 2023 publiqué aquí mismo, en El Lado del Mal, aquel primer artículo titulado «El proyecto del Country-Code Top-Level-Domain .IA para la Isla Anticitera: Conectando pasado y futuro con un Domain Hack», agradecí a Chema Alonso que me prestase su altavoz tras escribirle por MyPublicInbox para compartir lo que yo mismo bauticé entonces como «una idea loca loquísima».

    Hoy vuelvo a estas páginas para contaros qué ocurre cuando te tomas una «idea loca» con mentalidad de ingeniero: hemos auditado el sistema operativo jurídico de la Unión Europea, hemos encontrado la llamada al sistema adecuada y hemos logrado que la Comisión Europea registre oficialmente la iniciativa en Estrasburgo.

    De pedir firmas en Internet a ejecutar un «Legal Hack» en Estrasburgo

    Al principio hicimos lo que hace todo el mundo cuando quiere cambiar algo: abrir una petición simbólica en Internet para hacer ruido. Pero pronto entendimos una verdad incómoda de la ingeniería institucional: las plataformas privadas de firmas no tienen permisos de escritura (root) en el Boletín Oficial de la Unión Europea.

    Bruselas no mueve un sólo engranaje regulatorio por mucho ruido que hagas en redes sociales si no utilizas sus propios protocolos vinculantes. Así que decidimos hacer lo que haría cualquier hacker ante un sistema cerrado: leer la documentación técnica de los Tratados Europeos.

    Descubrimos que existe un mecanismo constitucional de democracia directa capaz de obligar jurídicamente a la Comisión Europea a tramitar legislación comunitaria: la Iniciativa Ciudadana Europea (ICE) regulada por el Reglamento (UE) 2019/788. Pero para atravesar el primer cortafuegos —el examen de admisibilidad jurídica de los servicios legales de Bruselas— teníamos que superar dos barreras que tumban a la mayoría de propuestas:
    • El Comité de las Siete Naciones: Levantar una alianza ciudadana internacional encabezada por al menos siete ciudadanos residentes en siete Estados miembros distintos de la Unión Europea.
    • La prueba de competencia estricta de los Tratados: Demostrar artículo por artículo que la Comisión Europea tiene competencia legal real para legislar sobre un dominio de nivel superior .IA sin salirse del Tratado de Funcionamiento de la Unión Europea (TFUE).
    Junto al co-representante griego Aristeidis Tsitiridis y un comité multinacional forjado entre España, Grecia, Francia, Portugal, Hungría, Croacia y Chipre, armamos un expediente jurídico milimétrico apoyado en los artículos 16, 114, 172 y 173 del TFUE y en el precedente directo del Reglamento (UE) 2019/517 (la norma comunitaria con la que la Unión Europea creó y gobierna el dominio .eu).


    El resultado llegó el 6 de octubre de 2026. Reunido en Estrasburgo, el Colegio de Comisarios de la Unión Europea adoptó la Decisión de Ejecución C(2026) 7098 final —un documento histórico donde, por cierto, el texto en lengua española es el único auténtico—, declarando jurídicamente admisible y registrando oficialmente nuestra iniciativa bajo el código ECI(2026)000012:

    «Creación del Distrito Digital Europeo (.IA) para la Gobernanza de la IA Soberana»

    Gobernanza compilada en el DNS: Por qué el .IA no es solo una etiqueta estética

    Cuando los juristas de la Comisión Europea examinaron nuestro expediente, vieron que no les estábamos pidiendo un simple capricho lingüístico, sino una solución de arquitectura para el mayor problema que tiene hoy la regulación tecnológica en Europa.

    Europa ha aprobado leyes pioneras como el AI Act (Reglamento de Inteligencia Artificial), el RGPD o la cartera de identidad digital eIDAS 2.0, pero para el ciudadano de a pie o para una PyMe es casi imposible distinguir a simple vista qué servicio de IA cumple realmente con sus derechos y cuál es una caja negra opaca alojada en un paraíso de datos.

    La propuesta admitida a trámite en la Decisión C(2026) 7098 final resuelve esa desconexión mediante tres engranajes legislativos concretos:

    1.- Soberanía en la raíz de Internet (ISO 3166 + ICANN): Mandato para que la Comisión Europea ejerza sus competencias de representación exterior y negocie ante la ISO (Agencia de Mantenimiento ISO 3166) y la ICANN/IANA la reserva, protección y delegación del espacio de nombres .IA (vinculado a Anticitera) como activo estratégico de soberanía digital europea, siguiendo el camino que ya abrió el dominio .eu.

    2.- El «Pasaporte Único» integrado en la resolución DNS (eIDAS 2.0 + AI Act + RGPD): Aquí reside el verdadero giro técnico. Proponemos que el registro y la propia resolución técnica de un dominio .ia integren por diseño tres garantías verificables para el usuario: Identidad Digital Soberana (eIDAS 2.0), auditoría algorítmica transparente (AI Act) y protección estricta de datos personales (RGPD). En lugar de enterrar la ética en PDFs legales que nadie lee, la confianza queda embebida en la propia infraestructura del nombre de dominio: si opera bajo .ia, cumple por arquitectura.

    3.- Distritos Digitales de Alta Confianza y Sandboxes Regulatorios: Para que las startups, universidades y centros de investigación europeos no mueran asfixiados por el papeleo frente a los gigantes de EE. UU. o Asia, el marco comunitario promueve «Distritos Digitales de Alta Confianza» y entornos de prueba (sandboxes regulatorios) bajo los artículos 172 y 173 del TFUE, permitiendo innovar en suelo europeo con agilidad técnica y seguridad jurídica desde el primer día.

    La cuenta atrás hacia el 6 de abril de 2027: Alistarse hoy para el Día 1

    Conseguir que Estrasburgo firme la Decisión C(2026) 7098 final nos ha entregado las llaves de la infraestructura oficial de votación de la Unión Europea, pero ahora empieza la verdadera partida de ajedrez.


    Según el artículo 8.1 del Reglamento (UE) 2019/788, desde la fecha de registro en Estrasburgo (6 de octubre de 2026) disponemos de un plazo legal exacto de 6 meses de preparación antes de que se abra la ventana oficial de recogida de firmas. Eso sitúa el encendido oficial de las urnas en una fecha matemática e inamovible: el martes 6 de abril de 2027 a las 09:00 CET.

    A partir de ese minuto exacto del 6 de abril de 2027, el reloj correrá durante 12 meses para lograr una hazaña ciudadana histórica: 1.000.000 de firmas verificadas en toda la Unión Europea, superando además los umbrales mínimos oficiales en al menos 7 Estados miembros (en España nuestro umbral mínimo legal es de 41.595 firmas).


    Por eso hemos construido y desplegado en los 24 idiomas oficiales de la Unión Europea la consola de lanzamiento del proyecto:


    El reloj astronómico que veréis latiendo en anticitera.deft.work/6abril está programado para transformarse automáticamente el 6 de abril de 2027 a las 09:00 CET en la pasarela directa de votación conectada al Sistema Central de Recogida en Línea (OCS) de la Comisión Europea.

    ¿Cómo puedes sumarte hoy mismo a esta maniobra?

    1. Apúntate en la «Lista de Pioneros · Día 1»:Deja tu correo electrónico. Cero spam y cero ruido: recibirás un único aviso prioritario en el instante exacto en que Bruselas habilite la urna oficial el 6 de abril para que puedas firmar en 30 segundos.
    2.- Pásalo a tu red en cualquiera de los 24 idiomas de la UE: Hemos integrado en la plataforma botones directos para compartir la cuenta atrás con mensaje precargado por WhatsApp, Telegram, X o LinkedIn en español, inglés, francés, griego, portugués, alemán, italiano y el resto de lenguas oficiales de la Unión.

    3.- Alianzas con universidades, empresas, divulgadores y comunidades tech: Si representas a una universidad, colegio profesional, medio de comunicación, empresa tecnológica o comunidad de desarrolladores, marca la casilla de colaboración activa en el propio formulario de https://anticitera.deft.work/6abril/ o escríbeme directamente a través de mi buzón en MyPublicInbox.

    Hace más de dos milenios, unos ingenieros griegos demostraron que el movimiento del cosmos podía modelarse con ruedas dentadas de bronce. Hoy tenemos a nuestro alcance que la Inteligencia Artificial hable en nuestro idioma, lleve nuestro nombre (.IA) y se rija por nuestros derechos. El código legal ya está compilado en Estrasburgo. El 6 de abrilabrimos las urnas. 

    ¿Te vienes a hacer historia en el Día 1?

  • Hoy os dejo una conversación - entrevista entre dos hackers a los que quiero, admiro, con los que he trabajado mucho, y con los que disfruto de hacer siempre cosas. Con ellos he escrito libros, he hecho proyectos, he trabajado en las mismas empresas, he dado charlas, y sobre todo, he compartido la pasión de la seguridad informática, la tecnología y el Hacking. Son Fran Ramírez y Javier Álvarez. 
    La charla es sobre hacking, ciberseguridad, IA y tecnología en general, y por supuesto Fran Ramírez tiene larga experiencia en eso. Sus años viendo nacer y crecer la informática hace que tenga una visión panorámica muy similar a la mía, pero además con una pasión por los detalles y las anécdotas de la historia de los hackers muy singular.

    Y cuando se sienta con Javier Álvarez, mucho más joven, con una experiencia brutal en las nuevas tecnologías - escribió conmigo el libro de Quatum Security: Tecnología Cuántica & Ciberseguridad.Criptográfica Cuántica y Post-Cuántica - surge la magia. Porque además han sido compañeros en el equipo de Ideas Locas, así que tienen una complicidad especial, como puedes ver durante toda la conversación.


    Figura 3: De Hacker a Hacker: Fran Ramírez vs. Javier Álvarez

    Así que, si quieres pasar un rato entretenido, aprender, y contagiarte de la pasión que tenemos nosotros con este mundo, no debes perderte la charla entre ambos compañeros y amigos. Los dos están en MyPublicInbox, así que puedes contactar con ellos cuando quieras para hacer proyectos o proponerles cosas, que son unos enamorados de nuestro mundo.

    A lo largo de mi vida he sido muy afortunado por muchas cosas, por trabajar y vivir de mi pasión, por las cosas que he podido vivir - y las que tengo por delante -, pero entre ellas está sin duda haber conocido a gente como estos dos compañeros de viaje. Fran y Javier. Más que agradecido estoy por ello. Disfrutad de lo buena gente que son un rato.

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  


  • No soy de los que me suele costar el cambio. Me adapto bien. No soy de los que espera que pase algo. No soy de los que se sienta en el sofá a esperar. No. Pero sí que he conocido a mucha gente así. Gente que ha pasado tiempo en el sofá luchando contra sí mismo. Sufriendo una indefinida monotonía en un trabajo que no le gusta, que no le llena, y que le va drenando cada día más. Contando los días que va desperdiciando uno a uno.
    No es una historia rara. Vivimos en una sociedad donde el miedo nos rodea. La manipulación se hace por el miedo, como os conté en el trabajo de "Fear of the Dark: Retórica IA". "¿Dónde vas a ir con lo bien que estás? ¿Y qué vas a hacer tú? ¿Y si te sale mal?"son cosas que dicen los de tu círculo que también tienen miedo. Aunque realmente les da más miedo que alguien haga lo que ellos no pudieron. Y esas palabras que te dicen, acaban en una lucha encarnizada dentro de ti.

    Te dices lo que quieres hacer. Te dices que sólo hay una vida. Pero las palabras y el miedo con el que nos bombardea alrededor hace que la batalla se salde en tablas. No desesperas en tu idea de hacer algo distinto, te quedas en el sofá, pero te das tu medicina de SOMA en forma de excusas. "Mejor espero a ver qué pasa con esto". "Lo mismo me ascienden". "Puede ponerse muy feo esto". Miedos en forma de excusa que nos meten alrededor. En mi caso, como me dijo un sabio de la vida, un día: "tú no podías tener miedo porque no podías estar peor de ninguna manera".
    De esto va a el evento del próximo 20 de Octubre "Levántate del Sofá". De todos los que estáis sentados en ese sofá, real o metafórico, que se va pegando a ti y cada día hace que te cueste más salir de él. Por miedo. Pero que al mismo tiempo estás sufriendo por que sabes realmente que lo que tienes y lo que haces no es lo que quieres. Sabes que tú vida se está yendo, y la estás malgastando. Y quieres hacer algo.

    Figura 4: Jero García estará en Levántate del Sofá

    En el evento, que tiene un número muy reducido de plazas, estarán David de Santiago y Jero García, dos que han estado en el Sofá hasta que un día se levantaron de él. Dejaron sus vidas anteriores atrás y comenzaron nuevos caminos. No sencillos, no fáciles. No cómodos. No calentitos como el sofá. Pero que le han llenado mucho más su vida. Y estarán allí para compartir con vosotros sus historias.

    El precio del event son 15€por persona, y 25€ si vais dos personas juntas, pero si además tienes Tempos de MyPublicInbox que hayas conseguido en la plataforma - con Tempos por Tweets, campañas, regalos de los libros de 0xWord o de eventos donde hayas asistido -, puedes entrar en la Nueva Tienda de MyPublicInbox y canjearlos por entradas para eventos.
    Allí, por 1.000 Tempos tienes la entrada para el evento de Levántate del Sofá. Cuando canjees tus Tempos por la entrada, recibirás un código que deberás usar en la web de registro y te dejará la entrada gratis totalmente para ti.
    Además, los asistentes se llevarán INCLUIDO EN EL PRECIO DE LA ENTRADA, el libro de "Todo Llega" donde David de Santiago cuenta su experiencia en el mundo profesional, en su faceta como emprendedor, y sus aprendizajes a lo largo de su carrera. 
    Una de esas partes tuvo que ver conmigo, ya que nuestros caminos se cruzaron en ElevenPaths y luego en Telefónica, donde hicimos muchas cosas juntos. Además, él cuenta cosas de mí, de mi carrera profesional desde mis inicios en Móstoles, y muchas más cosas.

    Así que, si este Martes 20 de Octubre estás por Madrid, a las 18:00 puedes ir al evento de "Levántate del Sofá", que es una de las cosas que debes hacer si estás peleando con tus excusas para moverte y hacer algo. Esta es una de mis batallas personales con mis hijas, así que no las dejo nunca que se sienten en el sofá... a por los retos, Levántate del Sofá ya.

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  


  • Tuve mi primer ordenador a los 16 años. No tenía disco duro. Solo una enorme disquetera de 5¼pulgadas y MS-DOS. No aprendí a programar entonces, pero hice algo que acabaría marcando mi forma de entender la informática: me leí la ayuda de prácticamente todos los comandos. Quería saber qué hacía cada instrucción, de dónde venían los datos, adónde iban y qué relación existía entre lo que escribía en la consola y lo que terminaba almacenado en aquel disco. 

    Figura 1: Cómo recuperar claves de Wallets de Criptomonedas Exodus.
     "Not Your Keys, Not Your Coins"... ¿o tal vez sí?

    Así aprendí a “robar” los programas de diseño gráfico para poder instalarlos en mi primer ordenador que me compré con 18 años, copiando los archivos disquete a disquete, copiando las instrucciones de archivos .ini de Windows, creando directorios… Aprendí a lo bruto!

    Parte I: La movida.

    Décadas después, el mundo cripto me ha devuelto exactamente esa sensación. Existe una idea muy asociada a Warren Buffett: no pongas dinero en algo que no comprendes. Yo descubrí hasta qué punto eso era cierto cuando sufrí mi primer problema serio con una wallet.

    Utilizaba Exodus con pocos fondos para experimentar. En una ocasión quise instalarla como extensión en un navegador. No encontré una extensión oficial en la web de Exodus, pero sí una que aparentaba serlo en el marketplace del navegador. Introduje mis 12 palabras: No funcionó. Lo intenté varias veces y me marché a trabajar. Horas después descubrí que los fondos habían desaparecido. Ahí aprendí mi primera gran lección sobre autocustodia.

    Yo había configurado una contraseña en Exodus y, de alguna manera, había dado por supuesto que aquella contraseña protegía la wallet en cualquier lugar, como sucede con cualquier cuenta en la nube. No comprendía todavía que aquella contraseña protegía fundamentalmente esa instalación local, mientras que quien dispusiera de mis 12 palabras podía reconstruir el acceso a los activos desde otra aplicación compatible. La lección fue cara, aunque la cantidad fuera pequeña: las verdaderas llaves eran aquellas palabras.

    Pasó el tiempo. Seguí leyendo sobre Bitcoin, blockchain, DeFi y wallets, hasta que otro problema volvió a empujarme hacia dentro de la tecnología. Durante unas pruebas con una tarjeta de débito vinculada a criptomonedas tuve que realizar una conexión que acabó provocando avisos de seguridad en mi wallet de pruebas de Exodus. La aplicación terminó restringiendo determinadas operaciones y el soporte técnico no conseguía ofrecerme una solución clara para mover algunos activos.

    Ante la impotencia hice algo muy sencillo: restauré las mismas 12 palabras en otra wallet compatible, a ver si funcionaba. Los fondos estaban ahí. Podía operarlos. Y entonces comprendí de verdad algo que hasta ese momento solo conocía superficialmente: la wallet no es el patrimonio. La wallet es una herramienta para acceder, mediante unas claves, a activos registrados en blockchain.

    Las mismas 12 palabras podían reconstruir las claves desde aplicaciones diferentes. Aquello despertó una pregunta mucho más interesante: ¿qué relación existe entre doce palabras que un ser humano puede escribir en un papel y las enormes cadenas de números que terminan controlando direcciones criptográficas? Ahí conecté el problema con otra investigación personal que llevaba desarrollando desde hacía muchos años: la sucesión de los números primos.

    BIP-39 utiliza una lista de 2.048 palabras. Empecé a estudiar sus posiciones y a representarlas mediante coordenadas asociadas a números primos. Esa representación no rompe BIP-39 ni reduce mágicamente su seguridad; me proporcionó, sobre todo, una forma matemática de estudiar las palabras, sus posiciones y las combinaciones válidas.

    Figura 3: “A los monos háblales de plátanos” o sustituir números por
    palabras como la manera más fácil de ayudar a recordar una clave,
     además de añadir conceptualmente un punto más de “dificultad”
     a la hora de “desencriptarla”.

    Con ayuda de un asistente de programación construí herramientas capaces de generar frases BIP-39 válidas y empecé a comprender algo que antes me parecía casi mágico: las palabras son una representación amigable para humanos de información binaria generada bajo reglas matemáticas muy concretas (a los monos háblales de plátanos). 

    Figura 4: 2048 palabras producen un número exageradamente grande de posibles
    combinaciones, pero es un número finito, concreto. La posibilidad de
    que tu frase semilla NO coincida con la frase semilla que obtenga
    otro usuario depende únicamente de capacidad de cómputo.

    Detrás de aquel simple papel con doce palabras había todo un universo. Y entonces decidí intentar el camino contrario. No preguntarme solamente cómo se genera una frase válida, sino:

    ¿Qué información deja una aplicación de wallet en un ordenador y hasta dónde puede llevarnos esa información?

    Parte II. La investigación técnica

    Empecé por Exodus Desktop en Windows. Analicé sus carpetas locales, sus copias de seguridad y posteriormente parte del código de la propia aplicación. Dos archivos aparecieron una y otra vez en la investigación:
    • passphrase.json
    • seed.seco
    Construí una herramienta experimental para estudiar esos archivos en mis propias wallets de pruebas. El resultado fue sorprendente. En determinados estados locales de Exodus sin contraseña configurada, el material almacenado permite descifrar una estructura interna que contiene información suficiente para reconstruir la frase BIP-39.

    Figura 5 El guardado local de archivos que contengan información de
    cualquier tipo de login es el eslabón más débil de la cadena.
    A partir de descifrar el mecanismo de generación de la clave,
    puede recorrerse el camino a la inversa:

    La aplicación que desarrollé no se limita a mostrar doce palabras. Reconstruye la información BIP-39, comprueba que reproduce correctamente el seed y deriva una dirección Ethereum estándar (funcionaría también con otras direcciones de criptomoneda). 

    Figura 6: No es magia, es cálculo.

    Después utiliza una dirección pública conocida únicamente como verificador del resultado. En mis pruebas apareció:

    BIP39 = OK

    MATCH

    Eso es importante porque también establece lo que no he descubierto. No se pueden obtener las 12 palabras simplemente mirando una dirección pública. No he roto BIP-39. No he reducido mediante números primos el enorme espacio criptográfico de búsqueda hasta hacerlo atacable. El elemento decisivo de esta recuperación es el material criptográfico que Exodus conserva localmente en determinados estados de la aplicación. Quedaba entonces una pregunta fundamental: 

    ¿Qué sucede cuando el usuario establece una contraseña? 

    Realizamos un experimento controlado con una wallet nueva y sin fondos. En el primer estado, sin contraseña, estaban presentes passphrase.json y seed.seco. La recuperación funcionaba. Después establecimos una contraseña: passphrase.json desapareció y seed.seco cambió. Ejecutamos de nuevo la herramienta sobre una copia exacta de aquel estado. Esta vez no pudo recuperar la frase.

    Posteriormente restauramos esa misma wallet mediante sus 12 palabras, sin establecer nuevamente contraseña. Exodus generó un nuevo passphrase.json y un nuevo seed.seco. La herramienta volvió a funcionar: 

    BIP39 = OK. MATCH. 

    Por tanto, el experimento produjo un ciclo muy claro:
    • Wallet sin contraseña →recuperación posible con el método estudiado.
    • Wallet protegida por contraseña → el método deja de funcionar.
    • Wallet restaurada de nuevo sin contraseña →recuperación posible otra vez.

    Y esto establece un límite esencial de mi investigación: hasta ahora no he demostrado ningún método para saltarse una contraseña de Exodus configurada correctamente. De hecho, nuestras pruebas muestran precisamente que establecerla bloquea el procedimiento que hemos reproducido. Pero aparece una segunda cuestión: si antes de establecer esa contraseña ya se generaron o conservaron copias locales correspondientes al estado anterior, proteger la wallet posteriormente no significa necesariamente que aquellas copias históricas hayan desaparecido. Y ahí podría encontrarse la verdadera superficie de riesgo. 
    Una posible mejora de diseño sería garantizar que el material sensible quede protegido antes de que se cree o conserve el primer estado local recuperable, ya sea mediante contraseña u otro sistema de protección adecuado.

    Esta investigación nació intentando recuperar una wallet y ha terminado recordándome una idea básica: “Not your keys, not your coins” no significa únicamente poseer las claves. Significa asumir la responsabilidad de protegerlas. Durante décadas hemos delegado la custodia de nuestro patrimonio en terceros. La autocustodia nos permite recuperar una parte de esa soberanía, pero también devuelve al propietario una enorme responsabilidad. 

    Y resulta fascinante que algo tan importante pueda quedar representado por 12 ó 24 palabras escritas en un pequeño papel (recuerda, a los monos háblales de plátanos). Detrás de esas palabras existe criptografía, entropía, funciones hash, derivación de claves y una enorme estructura matemática. No necesitamos comprenderla completamente para utilizarla. Pero sí necesitamos comprender el valor de aquello que estamos custodiando.

    Esta investigación se encuentra todavía en una fase inicial. El primer resultado reproducible lo he obtenido estudiando Exodus Desktop en Windows, y las conclusiones deben limitarse por ahora a ese entorno y a las versiones analizadas. El siguiente paso será ampliar la metodología, de forma controlada y responsable, a otras wallets del mercado para estudiar cómo almacenan y protegen localmente el material necesario para recuperar una frase semilla.

    Parte III: Criptografía y Criptomonedas

    Puede que Exodus sea un caso particular. Puede que encontremos comportamientos similares en otras aplicaciones. O puede que encontremos arquitecturas completamente diferentes. Eso es precisamente lo que toca investigar ahora.

    Hay que recordar también que este año, el equipo de Google Quantum AI,junto a la Fundación Ethereum,publicó en marzo otro paper clave titulado "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities". En este caso, lograron reducir a menos de 500.000 qubits físicos el requisito para romper la criptografía de curva elíptica (ECDLP-256) que protege a Bitcoin y Ethereum, permitiendo un ataque en cuestión de minutos.

    Éste es un tema delicado, ya que obliga a cambiar las bases del código de Bitcoin y esto requeriría un "Hard Fork" que afectaría a toda la red, desde desarrolladores hasta mineros, ya hay propuestas concretas sobre la mesa. Recientemente, investigadores de Blockstream han planteado una solución: migrar hacia firmas basadas en hash, con algoritmos de Post-Quanum Cryptography específicamente un esquema basado en SLH-DSA (Formerly SPHINCS+)

    Parte IV: Conclusiones finales sobre la investigación

    A esta investigación se suma una posibilidad especialmente esperanzadora: 

    Que determinados usuarios que hayan perdido sus 12 ó 24 palabras semilla puedan llegar a recuperarlas a partir de datos locales que todavía conserven y, con ellas, recuperar el acceso a activos que consideraban perdidos.

    Pero esa oportunidad abre al mismo tiempo un importante desafío jurídico y fiscal. Una herramienta capaz de recuperar credenciales de autocustodia no debería utilizarse simplemente porque alguien afirme ser propietario de una wallet: habría que establecer procedimientos sólidos para acreditar la titularidad o el control legítimo de los activos, obtener una autorización expresa para intervenir sobre los dispositivos y archivos y documentar la cadena de custodia y todo el proceso de recuperación ante notario.

    A ello se añade la cuestión fiscal y regulatoria, que dependerá de la jurisdicción de residencia del usuario y de las circunstancias concretas: procedencia de los activos, documentación histórica, obligaciones de declaración, eventual tributación y justificación de movimientos posteriores. 

    Por eso, convertir esta investigación en un servicio real de recuperación exigiría desarrollar, junto al procedimiento técnico, un protocolo jurídico, de cumplimiento y trazabilidad que permita distinguir una recuperación legítima de un intento de acceso a patrimonio ajeno. Poder devolver a una persona el acceso a un patrimonio que creía perdido sería una magnífica noticia; hacerlo con suficientes garantías para todas las partes constituye, al mismo tiempo, uno de los grandes desafíos que abre esta investigación.

    Mientras, aquella sensación que tenía a los 16 años ha vuelto: abrir una consola, no entender todavía todo lo que está ocurriendo y seguir investigando hasta descubrir de dónde vienen los datos, adónde van y qué sucede realmente entre medias.