Resumen

  • La edición congelada 20260828 declara 49.894 registros tanto en la cabecera como en sus resúmenes, pero contiene 48.214 líneas de datos según las exclusiones del formato RIR. IPv4 e IPv6 cuadran; ASN declara 16.000 y contiene 14.320.
  • Los archivos latest y fechado eran idénticos, y sus MD5 publicados coincidían con el cálculo independiente. Esa defensa descarta una diferencia ordinaria de transporte durante la captura, no la inconsistencia del conteo ni un error semántico en cada fila.
  • No existía delegated-lacnic-latest.asc. La firma fechada sí era matemáticamente válida, aunque fue creada en 2026 con SHA-1 y una clave DSA de 1.024 bits de 2002, fuera de la aceptación que exige OpenPGP moderno.

La resta antes de la criptografía

El archivo empieza con una declaración precisa: 2|lacnic|20260828|49894|19870101|20260828|-0300. El formato de intercambio de estadísticas de los RIR define el cuarto campo como el número de registros del archivo. Para obtenerlo hay que excluir la línea de versión, las líneas de resumen, los comentarios y los espacios en blanco. También define el valor de cada resumen como el número de líneas de registro de ese tipo, no como la cantidad de recursos representados.

LACNIC anuncia tres subtotales: 20.375 para IPv4, 13.519 para IPv6 y 16.000 para ASN. Sumados dan 49.894, exactamente la cifra de la cabecera. La consistencia entre metadatos parece perfecta.

El cuerpo ofrece otra cuenta. Hay 48.218 líneas físicas. Cuatro son la cabecera y los tres resúmenes; las otras 48.214 son registros. Las 20.375 filas IPv4 coinciden con su resumen. Las 13.519 filas IPv6 también. El bloque ASN tiene 14.320 filas. La diferencia entre 16.000 y 14.320 explica por sí sola las 1.680 líneas que separan la promesa del contenido.

Conviene frenar aquí cualquier conclusión espectacular. “Línea de registro” no equivale a “recurso”. El cálculo no encuentra 1.680 ASN desaparecidos. Tampoco identifica una delegación indebida, una base de datos dañada o una ruta incorrecta. Las filas examinadas conservan la forma esperada para el registro y el tipo de recurso. El hallazgo es que el control estructural definido por el editor no se puede reproducir con el artefacto que ese editor distribuye.

La diferencia sería menos relevante en una tabla meramente ilustrativa. Este fichero tiene otra función. El README de LACNIC lo describe como un resumen diario de asignaciones y adjudicaciones IPv4, IPv6 y ASN. La especificación obliga a ofrecer la edición más reciente bajo delegated-<registry>-latest, un nombre persistente pensado para trabajos automáticos. La cifra de registros es parte del protocolo entre productor y máquina.

Lo que LACNIC sí permite demostrar

La mejor defensa de LACNIC está en sus propios archivos. No hay que minimizarla.

Durante la captura, delegated-lacnic-latest y delegated-lacnic-20260828 eran idénticos byte a byte. Medían 2.311.991 bytes y compartían el SHA-256 95d59beaa4deb0ed5f40ae33a37210e11b4bce5b518613cfd4097fe442e7abf4. El ETag y la fecha de última modificación de las respuestas HTTP también coincidían. En ese momento, el alias corriente no llevaba a una edición distinta de la fechada.

Los dos acompañantes MD5 publicaban 30f2fac07e846d1706c1fa8c7bb0ebd6. Al recalcular el MD5 de cada archivo se obtuvo la misma cadena. La comprobación heredada funcionó para lo que puede observarse: no hubo una alteración accidental de los bytes entre la fuente y la captura.

La firma separada de la edición fechada también corresponde al archivo. Un verificador independiente leyó los paquetes OpenPGP, reconstruyó el hash y evaluó la firma DSA con la clave pública que LACNIC distribuye. La ecuación cerró. No existe base para calificar esa firma de falsificada ni para insinuar manipulación del fichero.

El antiguo formato común refuerza esa defensa. Exige un MD5 con el mismo nombre y extensión, y dice que una firma PGP adicional puede publicarse. La firma es opcional. Por tanto, la ausencia de una firma del alias no debe presentarse como incumplimiento directo de una obligación PGP que el texto nunca impuso.

La crítica empieza después de reconocer esos puntos: cada pieza responde una pregunta distinta, y ninguna pieza pública las une con una política moderna de aceptación.

La palabra “integridad” no basta

Un checksum responde si los bytes recibidos coinciden con un digest publicado. Ambos MD5 pasaron. Sin embargo, la RFC 6151 explica que MD5 ya no es aceptable cuando se necesita resistencia a colisiones. Puede conservar valor frente a errores casuales de transmisión, pero no debe confundirse con una atribución criptográfica moderna del editor.

Una firma responde quién autorizó unos bytes, siempre que la clave y los algoritmos sean aceptables. En el directorio de LACNIC, la ruta automática y la ruta firmada se separan. delegated-lacnic-latest.asc devolvía 404. En cambio, delegated-lacnic-20260828.asc estaba disponible, igual que la clave delegated-lacnic-key.

Un consumidor cuidadoso puede ensamblar la relación: descarga latest, lee 20260828, obtiene el archivo fechado, compara los bytes y verifica su firma. Ese procedimiento demuestra una relación en el puesto del consumidor; no es una manifestación firmada por LACNIC que diga que el alias observado correspondía a esa edición en ese momento.

La estructura plantea una tercera pregunta. Una firma correcta puede asegurar la identidad de un archivo internamente inconsistente. La criptografía conserva el error con gran fidelidad; no lo corrige. Por eso el conteo no es un detalle separado de la cadena de publicación.

La verdad semántica de las filas es aún otra cuestión. Este archivo es una instantánea, sin historial transaccional. No prueba rutas BGP activas, ubicación geográfica, propiedad económica ni uso actual. Este análisis tampoco lo intenta. Su objeto es más estrecho: qué afirma la publicación sobre sí misma y cómo puede comprobarlo un receptor.

Una firma válida que un OpenPGP moderno no debe aceptar

La clave principal publicada tiene la huella BED3BE6115A8AF036D271F9D3B8DD165F3FB5533 y el identificador 3B8DD165F3FB5533. Es una clave DSA con parámetro de 1.024 bits, creada el 12 de diciembre de 2002. Su identidad es Auto Zone Generator y la autocertificación examinada no declara vencimiento de la clave principal.

La firma fue creada el 29 de agosto de 2026. Usa DSA y SHA-1. El identificador del emisor coincide y la comprobación matemática es positiva.

La RFC 9580 obliga a mantener separadas dos frases que parecen contradictorias. Primera: la firma corresponde matemáticamente al archivo. Segunda: una implementación OpenPGP actual no debe generarla ni aceptarla. La norma prohíbe nuevas firmas SHA-1, la validación de firmas recientes dependientes de SHA-1 y la firma o verificación con claves DSA.

El ejercicio forense prueba qué mecanismo produjo el objeto; no concede una excepción operativa a la norma. Un sistema moderno que rechace la firma no está afirmando que la ecuación sea falsa. Está aplicando una política de seguridad que excluye el algoritmo.

NIST aporta un horizonte adicional al planificar la retirada de SHA-1 de toda protección criptográfica antes de finalizar 2030. Ese calendario es contexto de transición. No hace falta exagerarlo porque la regla específica de OpenPGP ya resuelve la aceptación de esta firma reciente.

El objeto que falta es pequeño

LACNIC no necesita convertir su archivo delegado en una autoridad central sobre las rutas. Necesita publicar una prueba compacta sobre su propia edición.

Un recibo moderno, firmado con una clave vigente y basado en SHA-256, puede reunir el serial y la fecha local; el nombre fechado y el alias latest; el tamaño y el digest; el total declarado y el número real de filas por tipo; la hora de corte y el huso; la huella, el algoritmo y la vigencia de la clave; y cualquier corrección o sustitución.

La versión de ese recibo situada junto a latest identificaría la edición fechada exacta. La copia fechada permanecería estable. Si el generador volviera a producir 49.894 en metadatos y 48.214 filas, el proceso tendría opciones visibles: impedir la publicación, registrar una excepción justificada o emitir después una corrección que enlace al objeto sustituido.

El cambio puede ser aditivo. Los archivos y MD5 antiguos siguen sirviendo a sistemas heredados. Los consumidores nuevos obtienen un camino aceptable. La rotación de clave incorpora una declaración de continuidad en vez de obligar a descubrir un ancla nueva por intuición. Los espejos pueden guardar los recibos aunque no conserven todas las instantáneas.

Esa pieza no garantiza que cada fila sea verdadera, y precisamente por eso es adecuada. Garantiza solamente hechos que el registro controla: qué publicó, cómo lo nombró, qué contó, qué clave lo autorizó y qué versión corrigió a otra. Es coordinación fina, no una licencia para decidir las políticas de red de terceros.

Límites del hallazgo

No hay prueba de ataque, compromiso, pérdida de recursos, fallo de rutas ni daño a un consumidor. No se conoce desde estos datos la causa del resumen ASN. Tampoco se ha demostrado que un programa concreto confiara en el número erróneo. El archivo más reciente y el fechado coincidían, los MD5 coincidían y la firma fechada era matemáticamente auténtica.

Lo demostrable basta: la cabecera no se reconcilia según su propia definición, el alias de automatización carece de firma homónima y la única firma fechada usa un camino que OpenPGP moderno ordena rechazar. La respuesta proporcional es cerrar esa cadena, no inventar un incidente.

Fuentes