Other meanings of Format-preserving encryption
Cryptography
Format-preserving encryption is an encryption technique that preserves the length and format of plaintext. It transforms values such as payment-card numbers, telephone numbers, dates, or identifiers into ciphertexts that remain valid members of the same prescribed domain, allowing older databases and input interfaces to handle protected data without redesign.
Format-preserving encryption protects a value while keeping it within a specified format and domain. Unlike ordinary block-cipher encryption, which commonly produces binary output of a fixed block size, FPE can turn a 16-digit decimal string into another 16-digit decimal string, or an alphanumeric identifier into another identifier of the same form.1 The format is more than visual appearance: a domain may exclude impossible dates, restrict characters, or require a particular length.
This property is useful when encrypted data must pass through legacy applications, database schemas, validation rules, or communications interfaces that cannot accept arbitrary ciphertext. FPE is therefore applied to structured data such as account numbers, national identifiers, medical record fields, and inventory codes. It does not conceal the existence, length, or broad type of the value, so those properties remain potential sources of information leakage.
FPE constructs a keyed permutation over a finite set of valid strings. Encryption maps each permitted plaintext to a different permitted ciphertext, while decryption reverses that mapping with the same key; for a fixed key, no two domain values share the same ciphertext.1 Common constructions adapt Feistel-style rounds and pseudorandom functions so that intermediate values can be represented in a chosen radix, such as decimal or hexadecimal.
The NIST standard specifies FF1 and FF3-1 for approved format-preserving encryption use, with restrictions on domain size, tweak handling, and implementation details.1 A tweak is a non-secret input that can separate contexts—for example, different fields or records—without requiring a different encryption key. It is normally transmitted or stored with the ciphertext, because secrecy is not its purpose.
FPE security depends on the size and structure of the domain, the construction, the key, and the surrounding system. A decimal field containing only a few possible values cannot provide strong confidentiality merely because it is encrypted; an attacker may enumerate the domain or exploit known formats. NIST therefore places minimum-domain and usage requirements on its standardized methods.1
FPE is encryption, not hashing, tokenization, or access control. Repeated plaintexts normally produce repeated ciphertexts when the same key and tweak are used, which can reveal equality patterns. Weak key management, predictable tweaks, excessive repeated queries, and unprotected metadata can undermine otherwise sound cryptography. Applications should also authenticate associated data and protect the key through established cryptographic key-management practices rather than treating format preservation as a complete security boundary.
Format-preserving encryption can operate on unusual finite domains, but preserving a semantic format is harder than preserving characters alone. A date field, for example, may require a domain containing only valid calendar dates; an identifier may include check digits, prefixes, or reserved ranges. Implementations must define whether such constraints are encrypted as one domain or handled separately, since ad hoc preprocessing can create collisions or leak structure.
Early FPE research examined arbitrary finite domains and helped move the subject beyond simple decimal strings.2 Later standardization narrowed the practical choices to constructions with specified security and parameter requirements. A notable edge case is short numeric data: preserving a familiar appearance may make migration easier, but the small domain can make guessing attacks feasible. FPE is consequently best suited to compatibility problems where the domain is sufficiently large and the threat model has been evaluated explicitly.
NIST terminology and approved-method status can change through revisions to Special Publication 800-38G; implementations should consult the current publication and applicable organizational requirements.
Help improve the encyclopedia. Reports go straight to the site manager.