Durante muchos años trabajamos con una certeza bastante razonable: si una evidencia digital era adquirida correctamente y su integridad quedaba respaldada mediante una función hash criptográficamente robusta, ese valor podía utilizarse posteriormente para verificar que los datos no habían sido modificados.

Esa afirmación sigue siendo válida.

SHA-256 continúa siendo un algoritmo criptográficamente robusto. No existe hoy un ataque práctico que permita sostener lo contrario y NIST continúa considerando aprobada la familia SHA-2. [1]

Entonces, ¿por qué plantear ahora un cambio? En realidad, mi propuesta no es abandonar SHA-256. Es incorporar SHA-3 como una segunda familia criptográfica y, a partir de allí, comenzar a pensar la preservación de evidencia digital bajo un principio más amplio: la agilidad criptográfica.

No porque sepamos que SHA-256 vaya a fallar. Precisamente porque no lo sabemos. Y porque, a mi juicio, lo que cambió durante los últimos años no fue la seguridad demostrada de SHA-256, sino nuestro nivel de incertidumbre respecto del futuro tecnológico.

Para una evidencia que puede necesitar ser verificada dentro de diez años, esa diferencia importa.

Lo que cambió no fue SHA-256. Cambió nuestra incertidumbre

Quiero ser particularmente cuidadoso con este punto porque el alarmismo no ayuda. La computación cuántica no ha roto SHA-256. La inteligencia artificial tampoco.

AES no está roto.

No hay ninguna razón técnica para afirmar hoy que debamos abandonar los algoritmos que utilizamos habitualmente. Pero tampoco creo que podamos proyectar hacia la próxima década, con la misma tranquilidad que algunos años atrás, las capacidades de cómputo y análisis criptográfico que conocemos hoy.

Hay al menos dos procesos diferentes detrás de esa incertidumbre.

Por un lado está el desarrollo de la computación cuántica, que llevó a NIST a desarrollar durante años un proceso específico de criptografía poscuántica y a publicar en agosto de 2024 sus primeros tres estándares FIPS destinados a resistir futuros ataques de computadoras cuánticas criptográficamente relevantes. [3]

Por otro lado apareció algo que, al menos para mí, resulta particularmente interesante: la utilización efectiva de modelos avanzados de inteligencia artificial en tareas de investigación criptográfica.

Son fenómenos distintos. No corresponde mezclarlos ni afirmar que uno potencia automáticamente al otro. Pero, desde la perspectiva de gestión del riesgo, ambos tienen algo en común: hacen mucho más difícil estimar cuáles serán nuestras capacidades tecnológicas dentro de diez años.

Y eso merece ser considerado cuando lo que buscamos preservar no es un sistema que renovaremos dentro de dieciocho meses, sino evidencia cuyo valor probatorio deberá sobrevivir al cambio tecnológico.

Algo que en 2023 no resultaba evidente

Vale la pena mirar sólo tres años hacia atrás.

En 2022 NIST abrió un nuevo proceso para incorporar algoritmos adicionales de firma digital poscuántica. El plazo para nuevas propuestas cerró en 2023 y comenzó la evaluación de decenas de candidatos. Uno de ellos era HAWK.

El algoritmo continuó avanzando durante el proceso y, en mayo de 2026, NIST lo incluyó entre los nueve candidatos seleccionados para pasar a la tercera ronda de evaluación. [4] Dos meses después ocurrió algo clave para este análisis: Investigadores de Anthropic, trabajando con Claude Mythos Preview, encontraron un ataque que reducía significativamente la fortaleza efectiva de HAWK. Según la información publicada, el sistema necesitó aproximadamente 60 horas para mejorar el mejor ataque conocido sobre un esquema que había sobrevivido dos rondas de revisión humana durante dos años. [5]

El resultado se publicó el 28 de julio de 2026.

Al día siguiente, los propios autores de HAWK confirmaron el impacto del ataque y retiraron el algoritmo del proceso porque elevar sus parámetros para compensar la nueva debilidad lo volvía poco competitivo. NIST actualizó ese mismo día su página de tercera ronda para reflejar el retiro. [6] [7]

Vale la pena aclarar que NIST no revocó un estándar. HAWK todavía era un candidato. Y, de hecho, que una debilidad sea encontrada durante el proceso de evaluación demuestra que el proceso funciona. Lo que me interesa es otra cosa.

En 2023, cuando comenzaba esa evaluación, ¿cuántos imaginábamos seriamente que tres años después un modelo de inteligencia artificial sería capaz de producir un resultado criptanalítico suficientemente relevante como para modificar la viabilidad de uno de los candidatos avanzados?

Yo, al menos, no lo hubiera considerado un escenario cercano.

Ese es el dato que me interesa. No HAWK en sí mismo. La velocidad con la que está cambiando nuestra capacidad de investigar criptografía.

El caso de AES es quizás todavía más ilustrativo

El mismo trabajo produjo resultados sobre AES. También aquí hay que evitar el titular fácil y amarillista. AES-128 completo utiliza diez rondas. No fue roto.

El trabajo se realizó sobre una variante reducida a siete rondas, como las que se utilizan habitualmente en investigación criptográfica para analizar el margen de seguridad de un diseño. [5]

Sobre esa variante, el sistema encontró una mejora significativa sobre el mejor ataque conocido: entre 200 y 800 veces más rápido, dependiendo de la métrica utilizada. El ataque sigue siendo completamente impráctico y no afecta AES-128 completo. [5]

Entonces la conclusión no puede ser: “la IA rompió AES”. No lo hizo.

Un sistema de inteligencia artificial consiguió producir investigación criptográfica novedosa sobre uno de los algoritmos más analizados de la historia.

Eso no demuestra una debilidad inmediata. Pero sí modifica una de las variables del problema: la cantidad y velocidad de capacidad intelectual que podemos aplicar al análisis de primitivas criptográficas.

Y cuando esa capacidad empieza a escalar mediante automatización, creo que resulta razonable revisar nuestras hipótesis sobre el futuro.

Diez años no es tanto tiempo

A veces hablamos de preservación de evidencia digital como si el problema fuera garantizar su integridad durante décadas. No hace falta ir tan lejos. Mi preocupación concreta es mucho más próxima. Diez años.

Una causa judicial, una revisión posterior, una contrapericia, un nuevo estudio sobre material secuestrado o cualquier discusión respecto de una evidencia puede producirse perfectamente dentro de ese horizonte.

Por eso no me alcanza con formular la pregunta de esta manera: ¿SHA-256 es seguro hoy? La respuesta es sí.

Me interesa otra pregunta: ¿Puedo adoptar hoy, con un costo razonablemente bajo, medidas que reduzcan mi dependencia de que una única familia criptográfica permanezca incuestionada durante los próximos diez años? Creo que también podemos responder que sí.

Y, si podemos hacerlo sin alterar la evidencia, sin eliminar los hashes existentes y sin transformar el procedimiento en algo impracticable, me parece razonable -y, claro está, recomendable- avanzar.

SHA-1, SHA-2 y SHA-3: la diferencia no es solamente la cantidad de bits

Para entender por qué propongo SHA-3 como primera incorporación, hay que hacer una pequeña distinción técnica. SHA-1 y SHA-2 no son el mismo algoritmo.

SHA-256 representa una evolución muy importante respecto de SHA-1 y no comparte las vulnerabilidades prácticas que llevaron al abandono de este último.

Sin embargo, ambos pertenecen a una misma tradición general de diseño.

Simplificando mucho, el mensaje es dividido en bloques que se procesan sucesivamente mediante funciones de compresión, manteniendo un estado interno que se encadena hasta producir el digest final. FIPS 180-4 especifica SHA-1 y la familia SHA-2. [1]

SHA-1 / SHA-2
Mensaje → bloques → función de compresión → estado encadenado → digest

SHA-3 parte de otra arquitectura.

NIST lo estandarizó en 2015 a partir de Keccak utilizando una construcción conocida como sponge y basada en permutaciones. [2]

SHA-3
Mensaje → absorción en un estado interno → permutaciones → extracción del digest

¿Por qué me interesa esa diferencia? No porque SHA3-256 tenga 256 bits y SHA-256 también. No estamos intentando “sumar bits”. Tampoco tendría sentido afirmar que usar dos funciones de 256 bits nos proporciona automáticamente 512 bits de seguridad. Lo importante es la diversidad arquitectónica.

Si calculamos SHA-256 y SHA-3 sobre exactamente la misma evidencia, estamos evitando que toda nuestra capacidad futura de verificación dependa de una única familia de diseño criptográfico. Eso es lo que busco.

No reemplazar. Incorporar.

Este es, para mí, el principio más importante de toda la propuesta. Si una evidencia fue adquirida hoy y posee un SHA-256 correctamente calculado y registrado, ese hash forma parte de su historia. No debería desaparecer. No debería reemplazarse dentro de cinco años porque decidamos utilizar otro algoritmo. Debería conservarse.

Si posteriormente incorporamos una nueva función, primero verificamos los valores históricos y luego agregamos la nueva representación criptográfica. La historia se acumula. No se reescribe.

Adquisición inicial

• SHA-256;

• SHA3-512;

• fecha y hora;

• identificación del objeto;

• herramienta utilizada;

• versión;

• operador;

• documentación de cadena de custodia.

Revisión posterior

• se verifica SHA-256;

• se verifica SHA3-512;

• si la política criptográfica cambió, se calcula una nueva función;

• se documenta el nuevo procedimiento;

• se preservan todos los digestos anteriores;

• se agrega el nuevo.

Ese mecanismo permite conservar algo parecido a lo que en otros ámbitos llamaríamos retrocompatibilidad. Cada nueva capa puede mirar hacia atrás y verificar la historia anterior.

Pero hay un problema práctico: no todas las herramientas permiten hacerlo

Hasta acá la propuesta puede parecer excesivamente sencilla:

“Calculemos SHA-256 y SHA-3 y listo”. No siempre funciona así.

Creo que hay que distinguir al menos dos escenarios.

1. Procesos en los que controlamos directamente el cálculo

Cuando trabajamos sobre archivos y podemos elegir las herramientas de hashing, calcular simultáneamente SHA-256 y SHA-3 es técnicamente sencillo.

Las bibliotecas criptográficas actuales permiten hacerlo sin dificultad. Incluso podemos implementar ambas funciones sobre el mismo flujo de lectura, evitando recorrer innecesariamente el archivo dos veces.

En la mayoría de los usos ordinarios, el costo adicional puede ser muy bajo. Aunque esto no significa que sea literalmente cero.

Cuando hablamos de imágenes forenses de varios terabytes o grandes repositorios, hay que medir tiempos, procesamiento y especialmente entrada/salida.

Pero estamos hablando de una penalidad operacional perfectamente evaluable, no de rediseñar la informática forense.

2. Herramientas comerciales con funciones predeterminadas

El escenario es diferente cuando el cálculo del hash está embebido dentro de una herramienta comercial.

Una aplicación puede generar automáticamente determinados digestos durante una adquisición o exportación y no permitir seleccionar SHA-3. Otra puede conservar algoritmos históricos por razones de compatibilidad. Y la organización que utiliza el producto no necesariamente tiene capacidad para modificar ese comportamiento.

Este es un problema real, pero creo que hay un error que deberíamos evitar: Confundir las capacidades de una herramienta con nuestra política de preservación de evidencia.

Si una aplicación produce SHA-256, ese valor debe conservarse. Pero nada impide que, sobre exactamente el mismo archivo o imagen, realicemos posteriormente una verificación criptográfica independiente y calculemos también SHA-3.

La herramienta comercial puede seguir cumpliendo su función. Nuestra política institucional no tiene por qué quedar limitada por ella.

La capa de integridad puede ser independiente de la herramienta forense

Este punto me parece particularmente importante. Las herramientas forenses especializadas cumplen muchas funciones: adquisición, análisis de sistemas de archivos, recuperación de datos, procesamiento de artefactos, indexación, búsquedas y presentación de resultados. No estoy proponiendo reemplazarlas.

Estoy proponiendo desacoplar de ellas la política institucional de integridad criptográfica.

Podemos conservar todos los hashes generados durante la adquisición original y, paralelamente, establecer un procedimiento común que genere los valores criptográficos que nuestra política considere necesarios. Nuevamente, bien hecho, no debería tener grandes penalidades.

Registro producido por la herramienta forense

1. identificación del software;
2. versión;
3. parámetros utilizados;
4. digestos generados automáticamente;
5. información de adquisición;
6. fecha y hora.

Registro criptográfico institucional

1. identificación de la evidencia;
2. nombre o identificador del archivo;
3. tamaño;
4. SHA-256;
5. SHA3-512;
6. identificación exacta de los algoritmos;
7. herramienta y versión utilizadas para el cálculo;
8. fecha y hora;
9. operador;
10. número de caso, expediente o referencia;
11. observaciones;
12. firma o sellado temporal, cuando corresponda.

No modificamos ni un byte del objeto. Sólo producimos representaciones criptográficas adicionales de la misma secuencia de datos.

Incluso podemos hacer algo mejor: una herramienta sencilla y auditable

Y acá aparece una posibilidad que me parece especialmente interesante. No tenemos necesariamente que esperar a que cada fabricante incorpore los algoritmos que una institución considera adecuados.

Un laboratorio, una organización, una empresa o incluso un profesional independiente podría disponer de una herramienta muy sencilla destinada específicamente a esta función. No una nueva suite forense. No otra plataforma compleja. Algo mucho más acotado.

Una herramienta que reciba uno o varios archivos, calcule simultáneamente los algoritmos definidos por la política vigente y genere un acta.

Por ejemplo:

1. identificación del archivo;
2. tamaño;
3. SHA-256;
4. SHA3-512;
5. fecha y hora;
6. identificador del caso;
7. operador;
8. versión de la herramienta;
9. observaciones;
10. información adicional definida por cada organización.

El acta podría ser configurable y responder a un formato previamente estandarizado por el laboratorio, la organización o el profesional. Y la herramienta podría ser de código abierto y auditable.

Esto último también merece una precisión. Que un programa sea de código abierto no significa automáticamente que sea seguro. No alcanza con publicar un repositorio y declararlo confiable.

Pero para una tarea deliberadamente sencilla —leer una secuencia de bytes, aplicar funciones criptográficas estandarizadas y producir un registro reproducible— la posibilidad de revisar el código, las bibliotecas utilizadas, las versiones y eventualmente el proceso de compilación puede resultar muy valiosa.

Incluso, en determinados contextos, puede ofrecer un grado de auditabilidad superior al de una función equivalente incorporada dentro de una herramienta comercial mucho más compleja. Y hay además una ventaja práctica que no es menor.

Estandarizar el digest también es estandarizar evidencia

Muchas organizaciones utilizan diferentes herramientas para diferentes investigaciones. Eso probablemente seguirá siendo así. Pero no necesariamente tienen que producir registros de integridad diferentes.

Una capa institucional independiente permitiría normalizar la manera en que se documentan los digestos, independientemente de qué producto haya intervenido en la adquisición o en el análisis.

El laboratorio podría tener un formato. La organización, otro. El profesional independiente, el suyo. Pero todos podrían aplicar un procedimiento reproducible y documentado.

Esto separa dos cuestiones que solemos mezclar: La herramienta que utilizo para investigar la evidencia y el procedimiento con el que preservo y documento su integridad criptográfica.

Creo que esa separación tiene mucho valor. Porque la primera puede cambiar con frecuencia. La segunda debería ser estable, auditable y, al mismo tiempo, capaz de evolucionar.

Eso es agilidad criptográfica

NIST viene trabajando explícitamente sobre el concepto de crypto agility: la capacidad de adaptar o sustituir mecanismos criptográficos en protocolos, aplicaciones, software, hardware, firmware e infraestructura preservando la seguridad y la continuidad operativa. [8]

Aplicado a evidencia digital, yo lo formularía de una manera particularmente conservadora:

Agilidad criptográfica no significa cambiar rápidamente de algoritmo. Significa estar preparado para incorporar nuevos algoritmos sin perder la capacidad de verificar todo lo anterior.

Esto es importante.

No quiero una política que diga: “Hoy usamos SHA-256. Mañana usamos SHA-3”. Quiero una política que diga: “Hoy usamos SHA-256 y agregamos SHA-3. Si dentro de algunos años necesitamos incorporar otra función, verificamos todo lo anterior, agregamos la nueva y conservamos la historia completa”.

Eso sí es un procedimiento criptoágil.

¿Por qué SHA-3 ahora?

Porque no tenemos que inventar nada.

SHA-3 está estandarizado por NIST desde 2015. [2] Tiene una arquitectura diferente de SHA-2. Está disponible en bibliotecas criptográficas ampliamente utilizadas. Y su incorporación puede realizarse con un costo técnico muy bajo en los procesos donde controlamos el cálculo; cuando la herramienta comercial no lo soporta, puede agregarse mediante una verificación independiente.

Mi propuesta inicial sería mantener: SHA-256 como referencia interoperable
e incorporar: SHA3-512 como segunda función de preservación.

SHA3-256 también sería una alternativa perfectamente válida.

Mi preferencia por SHA3-512 para este objetivo particular no surge de pensar que SHA3-256 sea inseguro. Surge simplemente de que, cuando hablamos de preservar evidencia y el costo adicional es marginal, el margen criptográfico adicional resulta razonable.

A lo que sí no le veo el sentido – y creo honesto mencionarlo-, es a calcular dos digestos SHA-256 y SHA-512, ambos de la misma familia solo por la mayor longitud del segundo. Puede aportar más margen criptográfico, pero no diversidad arquitectónica. Para el objetivo que planteo aquí, eso me parece un costo con un beneficio bastante menor que incorporar una segunda familia como SHA-3.

Pero tampoco quisiera convertir esta elección en el centro del debate. La cuestión importante no son esos 256 o 512 bits.

Es que el procedimiento quede preparado para que mañana podamos incorporar una tercera función sin modificar la evidencia, sin perder compatibilidad y sin tener que reconstruir nuestra cadena de confianza.

El hash tampoco hace magia

Hay una última distinción que considero necesaria. Un digest no demuestra por sí solo cuándo fue obtenido un archivo. No demuestra quién lo adquirió. No demuestra su procedencia. Y tampoco demuestra toda una cadena de custodia.

Permite verificar que una determinada secuencia de bytes coincide con otra secuencia que generó anteriormente el mismo valor, dentro de los supuestos de seguridad del algoritmo utilizado.

Por eso la fortaleza probatoria nunca reside exclusivamente en una cadena hexadecimal. Reside en el procedimiento. En cómo fue adquirido el objeto. En cómo fue documentado. En qué herramienta se utilizó. En qué versión. En quién realizó la operación. En cómo se registraron fecha y hora. En qué controles existieron. Y en la posibilidad de que un tercero pueda reproducir la verificación.

Agregar SHA-3 no reemplaza ninguna de esas cosas. Las complementa.

No sabemos qué ocurrirá dentro de diez años. Ese es precisamente el problema

No estoy sosteniendo que SHA-256 vaya a ser roto. No estoy sosteniendo que la inteligencia artificial vaya a descubrir mañana un ataque práctico contra SHA-2. Tampoco que la computación cuántica haya convertido en obsoletas las funciones hash que usamos actualmente.

Mi argumento es otro:

Hace apenas tres años había escenarios que parecían bastante más lejanos de lo que parecen hoy. En 2026 ya vimos sistemas de inteligencia artificial produciendo resultados criptanalíticos novedosos sobre HAWK y AES reducido. [5] Estamos atravesando simultáneamente una transición hacia criptografía poscuántica. [3]

Y, probablemente, todavía no comprendemos completamente cómo evolucionará la interacción entre mayores capacidades de cómputo, automatización de la investigación e inteligencia artificial.

Eso no es evidencia de que un algoritmo vaya a fallar. Es evidencia de incertidumbre.

Y la incertidumbre también se gestiona.

Si necesito preservar evidencia durante diez años y puedo reducir mi dependencia de una única familia criptográfica mediante una medida sencilla, económicamente accesible, auditable y que además deja preparado el procedimiento para futuras migraciones, creo que hay razones suficientes para hacerlo.

No se trata de abandonar SHA-256. Se trata de dejar de depender exclusivamente de SHA-256.

Podemos mantenerlo. Podemos incorporar SHA-3. Podemos registrar ambos. Podemos construir herramientas sencillas que estandaricen ese procedimiento.

Y, sobre todo, podemos establecer desde ahora una regla mucho más importante que cualquier algoritmo particular:

Los mecanismos criptográficos futuros se incorporan; la historia anterior no se reemplaza.

La confianza de una evidencia a diez años no debería depender de nuestra capacidad para adivinar qué algoritmo seguirá siendo considerado robusto en 2036. Debería depender de que hoy construyamos procedimientos capaces de evolucionar sin perder trazabilidad, reproducibilidad ni historia.

Ese, a mi juicio, es el verdadero sentido de aplicar criptoagilidad a la evidencia digital.