Format Preserving Encryption: FF1, FF3-1 and Where FPE Fits

Format preserving encryption (FPE) is encryption whose ciphertext has the same format as the plaintext, so a 16 digit card number encrypts to another 16 digit number and a nine digit identifier to another nine digit identifier. That property lets teams protect sensitive fields in legacy databases, message formats and test data without changing schemas or validation rules, which is why FPE is common in payments, healthcare and data masking products. It also makes FPE easy to misuse: small domains, fixed tweaks and the withdrawn FF3 method have all caused real weaknesses. This guide explains what FPE is, how the NIST FF1 method works, where FF3 and FF3-1 stand, how FPE compares with tokenisation and conventional encryption, and what to check before relying on it. It is written for security architects, data protection engineers and developers. For broader pseudonymisation choices, see the Pseudonymisation Techniques Guide.

Key takeaways

• FF1 is the method to use. The second public draft of NIST SP 800-38G Rev. 1 (3 February 2025) specifies FF1 only and states that FF3 is no longer specified, after attacks on both FF3 and its revision FF3-1.
• The current final standard still lists FF3. SP 800-38G (March 2016, updated August 2016) remains the final publication as checked on 8 November 2026, but NIST said in April 2017 that FF3 is no longer suitable as a general-purpose FPE method.
• Domain size is now a requirement. The Rev. 1 draft requires radix^minlen of at least 1,000,000; encrypting only the middle six digits of a card number sits exactly at that floor.
• FPE is deterministic for a given key and tweak. Equal inputs produce equal outputs, which keeps joins working but leaks equality and frequency; use variable tweaks where the data allows.
• The key is everything. FPE output is reversible by anyone with the key, so it is pseudonymised, not anonymised, data and key access is the real control boundary.

What it is

In plain terms, FPE maps every value in a defined set (the domain) to another value in the same set, using a secret key. If the domain is "strings of 16 decimal digits", every ciphertext is also a 16 digit string, so it fits the same database column, passes the same length checks and flows through the same file formats. Decryption with the same key reverses the mapping exactly.

Technically, NIST defines FPE methods as modes of operation of an approved block cipher, AES with a 128, 192 or 256 bit key. Each method takes four inputs: the key, a tweak, the plaintext as a string of numerals in a chosen radix (base), and the radix itself. The radix sets the alphabet: radix 10 for digits, radix 26 for lowercase letters, radix 36 for digits plus letters. The FF1 specification in the Rev. 1 draft allows radix from 2 to 2¹⁶ and message lengths from minlen to maxlen, with 2 <= minlen <= maxlen < 2³².

Because Rev. 1 is still a draft, treat its details as likely but not final. Its direction is clear enough to act on: build on FF1 and plan to retire FF3 and FF3-1.

How it works

FF1 is a Feistel network. The plaintext numeral string is split into two halves. In each of 10 rounds, one half is fed with the key, the tweak and the round number into an AES-based pseudorandom function; the result is reduced modulo radix^m and added to the other half; then the halves swap. Because each round only adds a keyed value to one half, every round can be undone with the same key, which is what makes the cipher invertible while staying inside the numeral alphabet. Decryption runs the rounds in reverse.

• Key: an AES key that must be secret and, per the draft, selected uniformly at random. It should be generated and held in a key management system or HSM. See the Cryptographic Key Management Guide.
• Tweak: a non-secret byte string, from zero bytes up to an implementation maximum. The draft says variable tweaks should be used as a security enhancement and recommends that the tweak vary with each encryption where possible, using data already associated with the plaintext (for example a record type or the last four digits kept in the clear).
• Radix and length: define the domain. The domain size is radix^length; the draft requires radix^minlen >= 1,000,000.
• Determinism: the same key, tweak and plaintext always yield the same ciphertext. There is no random IV, and there is no integrity tag, so FPE provides confidentiality only.

Domain size in practice

The draft's Appendix A explains why size matters. With g guesses, an attacker's chance of guessing a ciphertext's plaintext is g divided by the domain size, and analytic attacks on Feistel-based FPE exist when the domain is small. At the required 10⁶, the draft describes the data complexity to recover a target message as prohibitive. The NIST 2017 FF3 announcement made the same point the other way round: smaller domains, such as the middle six digits of a card number, could make the FF3 attack practical for many attackers.

Why it matters

• Legacy compatibility: protecting data in mainframe files, fixed-width records and applications with strict field validation, where changing column types is expensive.
• Analytics on protected data: deterministic output keeps joins, group-by and referential integrity working across tables and systems that share the key and tweak policy.
• Test and development data: realistic-looking values for non-production systems, with the option to decrypt under controlled conditions. See the Tokenisation and Data Masking Guide.
• Payments and identifiers: encrypting card numbers or national identifiers while keeping display digits in clear. Assessors decide how this affects scope, and the keys and decryption services remain in scope. See the PCI DSS 4.0 Guide.
• Data protection law: FPE output that can be reversed with a key held separately is pseudonymised data, which reduces risk but is still personal data under GDPR.

Common misconceptions

• "FPE is weaker encryption." FF1 with an adequate domain and a properly managed AES key offers strong confidentiality for what it protects. Its limits are determinism, no integrity protection and the domain size, not the cipher.
• "FF3-1 fixed FF3." FF3-1 was the 2019 draft's revision with a shorter tweak. The 2025 draft removes FF3 because of a tweak-schedule weakness that affected both FF3 and FF3-1 but not FF1.
• "Any field can be format preserving encrypted." Fields with small domains, such as PINs, months or short codes, fall below the required domain size and should be tokenised or encrypted conventionally.
• "FPE output is anonymous." Anyone with the key, or with access to the decryption service, can reverse it. Treat FPE data as sensitive and the decryption service as a privileged interface.
• "A fixed tweak is fine." The draft allows fixed tweaks but recommends variable ones; a single tweak across a large table maximises equality leakage and the data an attacker can collect under one tweak.
• "The library handles it." The 2025 draft disallows floating point in FF1 implementations after a bug in an earlier version of a widely used Java cryptography library. Use implementations tested against NIST example values and, for regulated systems, validated cryptographic modules. See the FIPS 140-3 and Cryptographic Module Validation Guide.

Related concepts

For the cipher modes underneath, see the Authenticated Encryption and Block Cipher Modes Guide. Tokenisation products often use FPE internally for vaultless tokens; ask vendors which method and parameters they use. See the Data Masking and Tokenisation Buyer's Guide.

Where identity fits

FPE moves risk from the data to whoever can call encrypt and decrypt. In most deployments that is a set of service accounts, API clients and batch jobs, not people. Give each application its own identity and key access policy, separate encrypt-only from decrypt rights, log every decrypt call, and alert on bulk decryption or decryption from unexpected workloads. If a key or a decrypting credential leaks, every value under that key is exposed; plan the response before it happens. See the Encryption Key Compromise Playbook.

Rolling it out and measuring it

1. Inventory fields: list candidate fields with their alphabet and length, and compute radix^minlen; drop any below 10⁶.
2. Choose FF1 and an implementation: confirm it matches NIST test vectors and avoids floating point arithmetic; replace any FF3 or FF3-1 use.
3. Define keys and tweaks: one key per data class and environment in a KMS or HSM; define the tweak source per field.
4. Pilot on a copy: encrypt a copy of production data, run application and reporting tests, and verify round-trip decryption on every record.
5. Cut over with rollback: keep the original data protected and recoverable until validation passes, then remove it.
6. Plan key rotation: FPE ciphertexts must be decrypted and re-encrypted to rotate keys, so schedule it as a data migration.

Useful measures: share of sensitive fields protected; number of fields below the domain floor still using FPE (target zero); remaining FF3 or FF3-1 usages (target zero); identities with decrypt rights per key; decrypt calls per day per identity against baseline.

Practitioner checklist

• Use FF1 for new FPE work; find and retire FF3 and FF3-1.
• Compute radix^minlen for every field and refuse FPE below 1,000,000.
• Generate AES keys in a KMS or HSM and never embed them in application code.
• Use variable tweaks drawn from associated data wherever the use case allows.
• Test implementations against NIST example values and avoid floating point arithmetic.
• Separate encrypt and decrypt permissions by service identity and log every decrypt.
• Treat FPE output as pseudonymised personal data, not anonymous data.
• Recheck the status of SP 800-38G Rev. 1 and update when a final version is published.

Standards and references

• NIST: SP 800-38G Rev. 1 (Second Public Draft), Methods for Format-Preserving Encryption
• NIST: SP 800-38G Rev. 1 Second Public Draft (PDF)
• NIST: SP 800-38G, Methods for Format-Preserving Encryption
• NIST: SP 800-38G Rev. 1 (Initial Public Draft)
• NIST: Recent Cryptanalysis of FF3
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Pseudonymisation Techniques Guide · Tokenisation and Data Masking Guide · Cryptographic Key Management Guide · Envelope Encryption and KMS Integration Patterns Guide