The ciphertext does not say which mode produced it.

8 min read

FORMAT-PRESERVING ENCRYPTION

The current revision draft removes FF3, requires a larger minimum domain, and the values in the database carry no metadata about how they were made.

The earlier article set out what format-preserving encryption leaves visible. This one is about a narrower and more urgent problem: the revision process has moved twice, deployments may not have, and the property that makes FPE convenient is the same property that makes the migration difficult to scope.

The timeline, with dates

Date	Event
March 2016	SP 800-38G published, specifying FF1 and FF3. Domain size required ≥ 100, recommended ≥ 1,000,000
2017	Durak and Vaudenay publish an attack on FF3
April 2017	NIST announces intent to reduce the FF3 tweak from 64 to 48 bits, or withdraw FF3
February 2019	Draft Revision 1: FF3 becomes FF3-1 with a 56-bit tweak. Minimum domain of 1,000,000 becomes a requirement for both FF1 and FF3-1, following analysis by Hoang, Tessaro and Trieu building on earlier work with Bellare
February 2025	Second public draft of Revision 1: FF3 is no longer specified. FF1 retains the one-million minimum domain requirement introduced by the initial draft. The inverse AES cipher is no longer permitted as CIPH. Floating-point arithmetic is disallowed in FF1 implementations
April 2025	Comment period closes

Three of those rows create migration obligations. The fourth creates an interoperability problem that will not surface until someone tries to move the data.

The arithmetic of the domain requirement

A minimum domain of 1,000,000 means at least six decimal digits must be encrypted. This is not a recommendation any more, and it eliminates several patterns that are in production everywhere.

Work through the common cases:

A sixteen-digit payment card, BIN visible, last four visible. Six digits encrypted. Domain = 10⁶. Exactly at the minimum, with no margin. And the domain seen by an attacker is smaller than that, because the visible BIN partitions the dataset: within one issuer prefix, the plaintext distribution is not uniform over a million values.

A four-digit branch, store or region code. Domain = 10⁴. Ten thousand values. Under a fixed key and a fixed tweak this is a codebook of ten thousand entries, and anyone with a handful of known plaintext-ciphertext pairs starts building it. The 2025 draft does not permit this. Neither did reality.

A national identity number with a visible check digit and a visible issuance-series prefix. Compute the domain per visible partition, never for the nominal identifier space. This is the calculation most deployments have never performed, and it is arithmetic rather than research.

The industry response to the raise is worth recording honestly, because it is a real disagreement rather than resistance to change. Comments submitted to NIST argued that raising the minimum from two decimal digits to six eliminates field-level encryption for four-digit fields, that this is a significant use case for payment data, and that encrypted-but-small is better than plaintext. NIST’s position is that below the threshold the mode does not deliver the security it claims, and that a mode which fails its own analysis should not be approved regardless of how convenient it is.

Both positions are defensible and the resolution is architectural rather than cryptographic: a four-digit field is not a candidate for FPE. It is a candidate for tokenization with a vault, for not being stored, or for a redesign of the field. Selecting a mode that the standards body has declined to approve for that domain size is a decision, and it should be recorded as one.

The property that makes the migration hard

Here is the specific difficulty, and it is not a matter of effort.

FPE ciphertext is a value in the same format as the plaintext. Sixteen decimal digits in, sixteen decimal digits out. It carries no algorithm identifier, no key version, no mode label, no tweak indicator. There is nowhere to put them; the whole point was that the field could not accommodate anything extra.

The consequence:

You cannot determine, by inspection, which mode, key or tweak produced a given value.

And trial decryption does not generally resolve the ambiguity because an accepted decryption under an incorrect key or tweak still produces a value in the permitted format. Decrypt a sixteen-digit ciphertext under the wrong key and the result is another sixteen-digit value. The same applies to a wrong tweak. There is no authentication tag or padding check to distinguish a correct decryption from an incorrect one.

This is the exact inverse of the situation with authenticated encryption, where a wrong key produces an unambiguous failure. Here, a wrong key produces confident nonsense.

Where a decimal check digit exists, such as Luhn on a payment card, it may reject roughly nine tenths of uniformly distributed wrong candidates and leave the rest. That is a heuristic, not a determination, and building a migration on it risks silently accepting incorrect plaintexts.

Therefore: a reliable migration depends on version information or another trustworthy discriminator outside the ciphertext. If a deployment recorded, per column or per record, the mode, revision, key version and tweak derivation used, the migration can be mechanical. If it did not, the work becomes data archaeology conducted against records whose correct plaintext may be difficult to verify.

That determination should be made now, before the revision is final, because the answer takes an afternoon to establish and years to remediate.

The floating-point clause

One line in the 2025 draft deserves separate attention because its consequences are delayed.

Floating-point arithmetic is disallowed in FF1 implementations. FF1’s round function involves modular arithmetic over large integers, and implementations that used floating point could produce results that differ from integer implementations at certain inputs.

For a system that encrypts and decrypts with the same library, this may remain invisible. For a long-lived data store, it can become an interoperability failure that manifests only at migration, years after the data was written, when the original library is unavailable or its behaviour is no longer reproducible, and when the ciphertext offers no way to identify the implementation that made it.

A cross-library interoperability test would establish whether this is theoretical or present in the field. As far as we can determine, none has been published.

The audit

The deliverable, and it is a query rather than a project:

Enumerate every FPE-encrypted column across the estate: table, column, radix, encrypted length, visible prefix, visible suffix, application owner.
Compute the effective domain per visible partition. Not for the identifier space; for what an observer of one partition actually sees.
Record mode, revision, tweak derivation and key version per column. Where this cannot be established from documentation or code, mark it. The count of columns you cannot label is the migration risk.
Test tweak stability. A tweak derived from a database row position, partition key or physical location becomes unrecoverable after a table reorganisation. Confirm the tweak input is derived from durable logical identifiers.
Measure equality leakage under each key and tweak policy. Deterministic FPE exposes equality when the same plaintext is processed under the same key and the same tweak. Group records by the effective key and tweak regime, then compare ciphertext repetition and frequency within those groups. A global COUNT(DISTINCT ciphertext) can mislead when tweaks vary.
Locate the integrity boundary. FF1 is not authenticated. A modified value decrypts to a different plausible value. Establish where tamper detection lives, or record that it does not exist.
Flag every column below 10⁶ and plan its exit. This is not a parameter change.
Confirm the FF3 population. Anything deployed between 2016 and 2019 may be FF3 with a 64-bit tweak, which is now unspecified rather than merely revised.

Item five is the one that changes conversations, because it converts a cryptographic property into a number a data protection officer can read.

Where this actually lands

FPE exists because a legacy interface could not carry ordinary ciphertext. That constraint is real in card processing, core banking, insurance policy administration and government registry systems built around fixed schemas. Those are often the systems least able to absorb a format change.

The pattern to watch for is FPE chosen not because a field could not be widened, but because widening it required coordinating with another team. That is a scheduling decision expressed as a cryptographic one, and it produces a column that will still be there when the mode is withdrawn.

The revision process has now moved twice while the visible format of the data stayed identical. An evolving specification combined with a ciphertext that carries no version metadata creates a transition that cannot be audited from the data alone.

Open work

Equality leakage in deployed columns. The distinct-ciphertext measurement, aggregated across real datasets, is unpublished. It is one query per column and the result would tell the field how much of the theoretical leakage is actually realised.
Cross-library FF1 interoperability. Do the widely used implementations agree, including at the boundaries the floating-point prohibition addresses? A small test harness would answer this permanently.
How many deployments can identify the mode of a given ciphertext? A survey question with, we suspect, an uncomfortable answer, and one that determines whether the coming migration is mechanical or archaeological.
What replaces FPE for sub-10⁶ domains? The industry comments to NIST identified a genuine gap. Comparing tokenization vaults, encryption with a schema change, and simply not storing the field across cost, availability and compromise properties is the architectural question behind those comments.

The fourth is the one with the widest audience, because everyone who loses a four-digit use case in the final revision will need an answer to it, and the standards process is not going to supply one.