Summary

  • RFC 9923 documents FNV as a fast, small, non-cryptographic hash and explicitly advises against it where collision or preimage resistance must be computationally infeasible.
  • Its security section models induced collisions in a bucketed table, including a possible Routing Information Base use, where correct lookups and updates can become progressively slower without the service necessarily disappearing.
  • The durable control is a measured recovery path: preserve the exact hashing epoch, detect abnormal concentration, change the function or offset_basis, rehash existing state and verify that latency and distribution recover.

The service was up; the table was getting slower

Consider a constructed operating scenario, not a reported incident. A network service answers health checks and continues returning logically correct results. Its average lookup time looks tolerable. Yet its high-percentile updates are taking longer, CPU queues are growing and a small number of table buckets hold increasingly long chains. Nothing has crashed. The data are still present. The service is losing time one collision at a time.

An uptime dashboard can call that system healthy. A user waiting behind one of the crowded buckets experiences a different reality. If the table sits on a route-processing path, a symbol-resolution path, a cache index or another high-rate control surface, the difference between “correct eventually” and “correct within the operating budget” is the difference between availability and degradation.

RFC 9923 gives that scenario a precise foundation. It records the Fowler/Noll/Vo family as fast, compact hash functions with useful dispersion, especially for many similar strings. The design has practical reasons to exist. URLs, hostnames, filenames, text, IP addresses and MAC addresses are among the kinds of input the RFC discusses. Fast processing and a small implementation footprint are advantages when the job is to spread ordinary inputs across a table, not to resist a determined search for collisions.

That distinction matters because “non-cryptographic” is not a synonym for “broken”. It defines the bargain. FNV spends little computation to produce a repeatable index. It does not spend the work needed to make collision, first-preimage or second-preimage attacks computationally infeasible. RFC 9923 therefore says it is not recommended for an application that requires those properties, and generally does not fit a security scheme facing an active adversary whose input can exploit the algorithm's low work factor.

What an FNV value actually depends on

The document concentrates on FNV-1a. The function starts from an offset_basis. For each input octet, it XORs that octet into the current hash value, then multiplies by a size-specific FNV_Prime, retaining the result modulo the selected power-of-two width. The RFC specifies 32-, 64-, 128-, 256-, 512- and 1024-bit sizes. It suggests FNV-1a for general FNV use because operational experience found better dispersion for small inputs than the older FNV-1 ordering.

A displayed hexadecimal result hides those dependencies. Two systems can receive what a human calls “the same record” and produce different outputs because they serialise fields in a different order, include different delimiters, normalise text differently, choose different widths or start from different bases. The output is not self-describing. A useful record must preserve the exact input bytes and the complete parameter set.

The offset_basis is especially important. RFC 9923 says almost any non-zero basis can serve in the general case, but hashes calculated with different bases will not interoperate. A non-standard basis can frustrate an adversary that must precompute collisions without seeing results. That limited benefit should not be inflated into cryptographic authentication. If the adversary can observe outputs, submit the empty string under suitable conditions or infer performance changes through repeated trials, the basis may be disclosed or worked around.

Representation creates another boundary. For persistent storage or interoperability across different hardware platforms, RFC 9923 requires an FNV hash to be represented in little-endian form. Compatible processes sharing memory may consistently use their processor's natural representation, but an integer-returning implementation on a big-endian system can appear byte-reversed against the standard byte vector. A comparison failure can therefore reveal a representation mismatch, not a change in the underlying object. Conversely, a numerical match says only that the chosen bytes and parameters reached the same output.

It does not establish who supplied them or whether they should be trusted.

From dispersion to a denial mechanism

The RFC's security example is deliberately simple. Imagine a table with n buckets. An item goes to hash(i) mod n, and items that land in the same bucket are linked together. That arrangement could support a compiler's symbol table or some Routing Information Base information in a router. As more items collect in one bucket, finding or updating one of them takes longer.

Collisions themselves are not proof of attack. A finite output space guarantees that distinct inputs will eventually share outputs, and reducing a hash modulo the bucket count creates further convergence. A table with a poor load factor, an unfortunate ordinary workload or too little capacity can develop long chains without hostile intent. The operator therefore needs a baseline, not a superstition that every collision is malicious.

The adversarial case begins when an input source can shape the distribution. If the function, basis and table mapping are known, an attacker can test candidates offline and prepare many distinct inputs that fall into the same bucket. Submitting the set then concentrates work without first probing the live service. An unknown basis can defeat that precomputation in the limited case where the attacker cannot observe outcomes.

The harder case is adaptive. If an actor can submit many variable inputs and detect which trials slow the service, it can collect apparent collision sets over time. RFC 9923 notes that this feedback problem is not magically removed by substituting a cryptographic hash. A cryptographic function changes what can be predicted or constructed from the algorithm alone; it does not prevent an observer from learning which inputs collide in one finite table through repeated interaction.

That is why the defence cannot be only “keep the seed secret”. The RFC describes detecting when an unusually large number of collisions is occurring and then rehashing the items with a changed algorithm—for FNV, perhaps a different offset_basis—before continuing under the new setting. It also notes that commercially deployed routers use such a technique to mitigate excessive collisions in internal tables, without naming them. The actionable point is the technique, not a vendor claim.

Rehashing is a state transition, not a parameter edit

Changing the basis creates a new hashing epoch. Every existing item that must remain findable has to move under the new mapping, or the lookup path must temporarily understand both the old and new epochs. Inserts arriving during the transition need an explicit destination. Readers need a rule for which table is authoritative. Memory, CPU and queue headroom must cover the rebuild. A rollback must not strand records that entered after cutover began.

Persistent hashes complicate the move further. If an FNV value is stored outside the process, embedded in a file format, sent to a peer or used as a stable identifier, changing width, basis, field order or byte representation is no longer a private table operation. It becomes a compatibility change. RFC 9923's little-endian rule and parameter constants are then part of the interoperability contract. A local recovery cannot silently rewrite an external meaning.

This is where a collision-recovery receipt becomes useful. Before rebuilding, retain the exact input encoding, FNV variant, width, prime, offset_basis, representation rule, table size and mapping. Preserve bucket occupancy, collision counts, load factor, lookup and update latency distributions, CPU and queue state, the observation window and the input population that triggered concern. Record who declared the condition and under which operating rule.

For the new epoch, record the replacement function or basis, implementation and version, start and completion times, treatment of concurrent reads and writes, number of items moved, compatibility bridge, rollback point and any items that could not be transferred. After cutover, repeat the distribution and latency measurements. “Rehash completed” is not recovery evidence unless the service consequence improved and all required state remained reachable.

The receipt should keep an explicit non-conclusion. A matching FNV result does not authenticate an actor, prove provenance, authorise a route, establish tamper resistance or guarantee semantic equality. Those propositions need their own controls. FNV can remain an excellent answer to a narrow indexing problem precisely because the system refuses to make it answer wider questions.

Useful standards references do not enlarge the promise

FNV appears in standards documents, but its role remains bounded. RFC 7357 gives an example in which FNV-32 helps an ingress TRILL RBridge choose among eligible egress RBridges. The purpose is pseudorandom distribution; the document even says different ingress devices need not use the same function. It is not a claim that the result authenticates an egress.

RFC 7873 offers FNV64 as a simple example for forming a DNS Client Cookie from client address, server address and a client secret. It also provides a more computationally expensive HMAC-SHA256 construction. DNS Cookies themselves supply limited protection against certain off-path attacks; they are not a replacement for DNSSEC data-origin authentication or general transaction security. The surrounding secret, inputs and protocol checks matter. The name of the hash does not carry the security property alone.

RFC 6234 provides the contrast. Secure Hash Algorithms are designed so that finding a preimage or two messages with the same digest is computationally infeasible under their stated security assumptions, and they are used with digital signatures, HMAC and key derivation. That does not mean every table index should pay for a cryptographic construction. It means the threat model must decide the tool.

Publication status requires the same discipline. RFC 9923 is an Informational Independent Submission, not an IETF Standards Track document and not a statement of IETF consensus. RFC 7841 explains why stream and status boilerplate matter: RFCs can originate through different review paths, and publication alone does not certify fitness for deployment. The correct response is neither dismissal nor automatic adoption. It is to use the documented mechanics within the proposition they support and test them against running conditions.

That is Running-Code Primacy in a small, concrete form. The document can specify constants, representation and known risks. The operator must still observe the table, validate the threat model and execute recovery. Publication is useful evidence. Running behaviour is the decision surface.

Sources