El hash de una infracción: para qué sirve en una integración

Una integración que consulta infracciones repite la misma pregunta muchas veces. Casi siempre la respuesta es igual a la anterior y lo interesante es detectar la vez que no lo fue. Comparar campo por campo sirve para dos registros, no para miles por día.

Un hash de contenido resuelve esa parte y sólo esa parte. El hash de una infracción es el resumen de longitud fija de una serialización determinística de los campos que elegiste observar, y responde “¿cambió lo que ya tenía?” sin recorrer el detalle.

Alrededor de esa función aparecen tres usos que parecen naturales y no lo son: identificar el hecho, probar el origen y ocultar la patente.

Qué pregunta responde y cuáles no

FIPS 180-4 define la familia SHA-2, que incluye SHA-256. De sus propiedades importan dos: cualquier cambio en la entrada produce, con probabilidad muy alta, un digest distinto, y encontrar dos entradas con el mismo digest es computacionalmente inviable. Alcanza para comparar: si el valor de hoy coincide con el de ayer, esa receta no vio cambios.

Lo que no responde es más largo: si dos observaciones corresponden al mismo hecho, quién produjo la respuesta o por qué cambió un campo. Tampoco dice si un archivo llegó completo: eso se comprueba sobre los bytes del artefacto, con su propio manifiesto.

La receta pesa más que el algoritmo

Dos sistemas que usan SHA-256 sobre “la misma infracción” pueden obtener valores distintos: la diferencia no está en la función sino en qué se le entrega. Antes de calcular hay que fijar cuatro cosas:

• qué campos entran y cuáles quedan afuera;
• cómo se normaliza cada valor: espacios, mayúsculas, fechas y moneda;
• cómo se serializa el conjunto resultante;
• qué versión de esa receta produjo el valor.

RFC 8785 cubre el tercer punto: define una serialización canónica de JSON —orden de propiedades, escape de cadenas y números— para que los mismos datos produzcan siempre los mismos bytes. Sin esa regla, un espacio de más o un reordenamiento de claves cambia el digest sin que cambie ningún dato.

Los dos primeros no los resuelve ningún estándar: son decisiones del contrato. Un campo volátil adentro, como el instante de la consulta, hace que el valor cambie en cada corrida y deje de señalar novedades. Uno ausente, como el monto o el estado, deja pasar un cambio real.

El cuarto es el que se olvida. Cuando la receta cambia, todos los digests cambian a la vez, y sin la versión guardada junto al valor la migración se ve igual que “cambiaron todas las infracciones”. Compará primero esa versión: si no coincide con la vigente, el resultado es “no comparable”, no “distinto”.

Un hash no es un identificador

El atajo tentador es usar el digest como clave, y falla en las dos direcciones. Si el hash es la identidad, una corrección de monto crea un registro nuevo en lugar de una versión nueva del mismo hecho: la identidad debería sobrevivir a lo que el digest existe para detectar. Y en la otra dirección, dos infracciones distintas cuyos campos observados coinciden comparten digest: la receta no distingue lo que no mira.

El diseño que funciona los separa: el identificador estable dice de qué hecho hablamos y el hash dice cómo se veía esa versión. La canonicalización evita que el digest se mueva por una reserialización, pero no lo convierte en clave de deduplicación: esa clave la declara el productor.

Integridad, autenticidad y anonimato

RFC 9530 define campos para transportar en HTTP el digest del contenido o de la representación. Detecta alteraciones, no acredita origen: quien pueda modificar el cuerpo también puede recalcular el valor. La autenticidad necesita una firma verificable con una clave.

El uso más riesgoso es tratar un hash de dato personal como anónimo. La guía de NIST sobre desidentificación es explícita: un hash sin clave no confiere seguridad, porque se pueden probar por fuerza bruta todos los valores posibles, y el formato de las patentes hace chico ese conjunto. Con una clave secreta el resultado es un seudónimo, no un anónimo; esa guía desaconseja usar hash o cifrado para proteger identificadores directos. Un hash de patente se cuida como la patente.

Cómo se prueba una receta

La verificación no necesita datos reales. Tomá una respuesta guardada, reordená sus claves, cambiá el espaciado y recalculá: tiene que dar igual; si cambia, la canonicalización no funciona. Modificá después un campo declarado: tiene que cambiar. Y uno excluido, como el instante de consulta: tiene que quedar igual.

Esas tres corridas describen la receta mejor que cualquier documento y se automatizan como test de contrato. Conviene una cuarta: que un digest de otra versión nunca se compare contra la vigente.

Antes de confiar en un hash, verificá que la receta esté escrita —campos, normalización, serialización, algoritmo y versión—, que ningún campo volátil entre en el cálculo, que haya un identificador estable independiente del digest y que ningún hash de datos personales circule como anónimo. El valor de un hash no está en la función elegida, sino en la disciplina del recorte que la precede.

Metodología

Alcance

Diseño y verificación de un hash de contenido sobre infracciones normalizadas dentro de una integración, con foco en la receta de cálculo y no en un lenguaje o proveedor particular.

Unidad de análisis

Una observación normalizada de una infracción y el digest calculado sobre el subconjunto de campos declarado para esa versión de la receta.

Cobertura

Propiedades de las funciones de la familia SHA-2, serialización canónica de JSON, campos de digest en HTTP y advertencias sobre hash de identificadores, según las fuentes citadas.

Limitaciones

• La elección de campos y su normalización dependen de cada contrato de datos; ninguna fuente externa puede fijarlas por vos.
• La nota no evalúa costos de cómputo ni el rendimiento comparado de algoritmos sobre volúmenes grandes.
• Detectar un cambio no explica su causa: distinguir corrección, retiro o error de la fuente requiere el vocabulario de eventos, no el digest.

Fuentes

• FIPS 180-4, Secure Hash Standard — National Institute of Standards and Technology (consultada el 2026-08-29)
• RFC 8785 JSON Canonicalization Scheme — RFC Editor (consultada el 2026-08-29)
• RFC 9530 — Digest Fields — RFC Editor (consultada el 2026-08-29)
• NIST Special Publication 800-188: De-Identifying Government Datasets — National Institute of Standards and Technology (consultada el 2026-08-29)

Preguntas frecuentes

¿Puedo usar el hash de contenido como clave primaria de una infracción?

No conviene. El hash cambia justamente cuando cambia lo que observás, así que una corrección de monto o de estado crearía un registro nuevo en lugar de una versión nueva del mismo. La identidad tiene que sobrevivir a los cambios que el digest está diseñado para detectar.

¿Dos sistemas que usan SHA-256 obtienen el mismo hash de la misma infracción?

Sólo si comparten la receta completa: los mismos campos, la misma normalización de cada valor y la misma serialización. Con la función criptográfica no alcanza, porque un espacio de más o un orden distinto de claves ya produce otro digest.

¿Hashear la patente sirve para anonimizarla en logs y métricas?

No. La guía de NIST sobre desidentificación señala que un hash sin clave no confiere seguridad, porque se pueden probar por fuerza bruta todos los valores posibles, y el formato de patente hace chico ese conjunto. Un hash con clave secreta produce un seudónimo, no un anónimo, y esa misma guía desaconseja apoyarse en hash o cifrado para proteger identificadores directos. Un hash de patente sigue siendo un dato asociado a un vehículo.

¿El hash prueba que la respuesta vino del proveedor correcto?

No por sí solo. Un digest transmitido junto al contenido detecta alteraciones accidentales, pero quien pueda modificar el cuerpo también puede recalcular el valor. Para acreditar origen hace falta una firma con una clave que el receptor pueda verificar.

Notas relacionadas