Summary

  • LACNIC's frozen 28 August 2026 delegated file declares 49,894 records but contains 48,214 record lines under the definition in the published RIR Statistics Exchange Format. The 1,680-line difference is entirely in the ASN summary.
  • The latest and dated files were byte-identical, and both MD5 companions matched. That rules out an ordinary transfer mismatch in this capture; it does not make the header count correct or prove the meaning of any row.
  • The persistent latest alias had no matching .asc. The dated file's signature verified mathematically, but it was a new SHA-1 signature under a 2002 DSA-1024 key—precisely the combination modern OpenPGP rules tell implementations not to accept.

A count that will not reconcile

The first useful fact is not cryptographic. It is arithmetic.

The frozen file begins 2|lacnic|20260828|49894|19870101|20260828|-0300. In the exchange format used by the regional Internet registries, the fourth field is not the amount of address space and not the number of individual ASNs. It is defined as the number of record lines, excluding the version line, summaries, comments and blanks. The three following summary lines are supposed to count record lines by type.

Those declarations add neatly. IPv4 contributes 20,375, IPv6 contributes 13,519 and ASN contributes 16,000. The total is 49,894, exactly the value in the version line.

The file itself does not add that way. It has 48,218 physical lines: one version line, three summaries and 48,214 resource records. IPv4 has 20,375 record lines, so that summary closes. IPv6 has 13,519, and that closes too. ASN has 14,320 record lines, not 16,000. The whole difference—1,680—sits in one declared type count.

This is where a sensational story would go wrong. Nothing in that calculation says 1,680 autonomous system numbers vanished. It does not show that a delegation is false, that a holder lost a resource or that a route was affected. The specification explicitly distinguishes record-line counts from the quantity of resources those records represent. The measured defect is narrower: a machine following the published validation rule cannot reproduce the publisher's declared count from the publisher's file.

That narrow defect matters because the file is made for automation. LACNIC's README describes daily summaries of IPv4, IPv6 and ASN allocations and assignments. The exchange format makes delegated-lacnic-latest a persistent name so system jobs can fetch the current edition without discovering a new dated URL. A validation field that cannot be reproduced at that boundary is not decorative metadata. It is a failed invariant.

The checks that did work

LACNIC has a serious defense, and it should be stated before the critique travels any further.

At capture, delegated-lacnic-latest and delegated-lacnic-20260828 were byte-for-byte identical. Each was 2,311,991 bytes. Each produced the same SHA-256 digest, 95d59beaa4deb0ed5f40ae33a37210e11b4bce5b518613cfd4097fe442e7abf4. Their HTTP metadata also carried the same ETag and last-modified time.

Both matching MD5 files published 30f2fac07e846d1706c1fa8c7bb0ebd6, and independent computation produced the same digest for both data objects. In the ordinary sense of detecting a truncated or accidentally changed transfer, the legacy check passed. There is no observed split between the alias and the dated edition, and no evidence here of tampering.

The dated detached signature also passed a forensic mathematical test. Its OpenPGP packets identify key ID 3B8DD165F3FB5533, part of fingerprint BED3BE6115A8AF036D271F9D3B8DD165F3FB5533, with the user ID Auto Zone Generator. Reconstructing the signed hash and applying the DSA verification equation to the published key returned true.

These are not minor concessions. They locate the problem. The bytes are consistent across the two names. The MD5 values correspond to those bytes. The dated signature corresponds to those bytes and that published key. What fails is not the ability to collect evidence; it is the absence of one current rule that makes the evidence cohere.

Three meanings of integrity

“Integrity” is often used as though it were a single property. This release exposes at least three.

Transfer integrity asks whether the file received is the file whose digest was published. The matching MD5 answers that limited question in this capture, despite MD5's obsolete collision resistance.

Publisher authenticity asks whether the release can be attributed to the holder of a trusted signing key under an acceptable algorithm. The dated signature supplies a mathematical relation, but the current-alias route does not expose a matching signature at delegated-lacnic-latest.asc.

Structural integrity asks whether the contents satisfy the publisher's declared schema and invariants. The record-line total does not. Neither a matching MD5 nor a valid signature repairs a signed mistake. They can prove that everyone received the same inconsistent file.

Semantic correctness is a fourth and harder question: whether each row accurately reflects registry state. This analysis does not answer it. A cryptographic signature cannot turn a delegated-statistics snapshot into proof of live routing, current geography, beneficial ownership or event history. That is the boundary already made clear by other work on RIR statistics. The present issue begins one layer earlier: even the file's own record-line accounting does not close.

The signature that does not follow latest

The distribution layout divides freshness from authentication. The exchange format says the most recent edition must be reachable through the persistent latest name for automated retrieval. It also says cryptographic signing is optional. If a registry signs, the recommended convention is the matching filename plus .asc.

At capture, the dated file followed that convention: delegated-lacnic-20260828.asc was present. The key was present as delegated-lacnic-key. But delegated-lacnic-latest.asc returned HTTP 404.

A careful consumer can work around this. Fetch latest, read its serial, construct the dated filename, prove the dated bytes equal the alias, then fetch the dated signature and the key. That is a method. It is not a publisher-signed statement that the alias pointed to that edition at a particular time. The consumer has assembled the join locally.

Local joins are tolerable when they are all governed by the same modern cryptographic acceptance policy. Here they are not. The primary DSA key was created on 12 December 2002, uses a 1,024-bit parameter and declares no expiration in the checked certification. The detached signature was created on 29 August 2026 with SHA-1.

RFC 9580 is unambiguous for contemporary OpenPGP. Implementations must not generate signatures with SHA-1. They must not validate any recent signature that depends on SHA-1. They must not sign or verify using DSA keys. The fact that an independent audit can still calculate the DSA equation is not a permission for a conforming modern implementation to accept the signature. Mathematical truth and protocol acceptance are different findings.

Nor does the old exchange format settle the modern question. It requires MD5 and makes an additional PGP signature optional. LACNIC therefore should not be accused of violating the optional clause merely because latest.asc is absent. The problem is more durable: an old distribution contract now leads automated consumers toward checks that cannot supply a single modern authenticity decision.

One release, one receipt

The smallest remedy is not a new registry database, a live-routing oracle or an approval gate. It is a release receipt.

For each daily edition, LACNIC could publish a compact manifest signed with a modern key and modern hash. The receipt would name the serial and local production date; the dated filename and latest alias; the byte length and SHA-256 digest; the declared and actual record-line counts, both in total and by type; the cutoff and time-zone offset; the signing-key fingerprint and validity; and any correction or supersession link.

The latest receipt would identify the exact dated edition. The dated receipt would remain stable. If a generator produced a count mismatch, the release process would either stop before publication or publish an explicit exception and later correction. A consumer would no longer need to infer whether a mismatch is an undocumented convention, a generator defect or a partial update.

This design preserves the thin layer. LACNIC states only what it is uniquely positioned to state: these are the bytes it released; this alias refers to this edition; these are the counts it asserts; this key authorized the release; this correction supersedes that one. Operators remain free to decide whether and how to consume the snapshot. No one is required to treat the file as routing policy.

Backward compatibility is possible. The existing data and MD5 names can remain for legacy systems. A SHA-256 digest and modern signed receipt can be additive. Key rotation can publish a cross-signed continuity record rather than silently replacing the trust anchor. Mirrors can retain the small receipts even if they do not retain every historical data object.

The important change is not algorithm fashion. It is moving the reconciliation rule back to the publisher. Today, each serious consumer must decide which count to trust, how to map latest to a dated signature and whether to waive modern OpenPGP policy. A shared release object would make those decisions visible, repeatable and correctable.

What this evidence does not prove

The frozen evidence does not prove a compromise, forged signature, missing resource, incorrect delegation, route leak or outage. It does not show that any consumer accepted a wrong row or suffered operational harm. It does not establish why the ASN summary is 1,680 above the actual ASN record-line count. It does not test LACNIC's internal generator or private controls.

It proves a public, reproducible mismatch and a split verification path. That is enough for a governance conclusion, but only a bounded one: a file intended for automatic use should ship with an authoritative, modern and internally consistent account of its own release.

Sources