Format Preserving Encryption (FPE) is a method of encryption that keeps the encrypted data in the same format and length as the original. A 16-digit card number encrypts to another 16-digit number, so protected data fits existing databases and applications without schema changes. FPE is defined by NIST SP 800-38G (modes FF1 and FF3-1) and is built on AES.
Format Preserving Encryption (FPE) is an encryption method that preserves the format and length of the data it protects: a 16-digit credit card number becomes a different 16-digit number, and a 9-digit Social Security number becomes another 9-digit value. This lets sensitive data be encrypted without breaking the databases and applications that expect a specific format. FPE is standardized in NIST SP 800-38G and is built on the AES cipher.
Key Takeaways
- FPE encrypts data while keeping its original format and length, so ciphertext fits the same database fields and application rules as the plaintext.
- It is standardized by NIST in SP 800-38G, which defines the FF1 and FF3-1 modes (collectively part of the FFX construction), all built on AES.
- FPE is ideal for structured sensitive data: credit card numbers (PANs), Social Security numbers, and other PII, and helps with PCI DSS and similar compliance.
- It differs from tokenization: FPE is reversible cryptography using a key, while tokenization swaps data for unrelated tokens tracked in a vault.
- Because FPE is AES-based and symmetric, it is quantum-resistant in the same way AES is; its security caveats (small domains, the earlier FF3 flaw) are classical, not quantum.
What Is Format Preserving Encryption?
Most encryption changes both the content and the shape of data: encrypt a 16-digit card number with standard AES and you get a long block of binary, unrecognizable and a different length. That is fine for a file, but it breaks a database column that expects exactly 16 digits, or an application that validates the format. Format Preserving Encryption solves this by producing ciphertext in the same format and length as the input. The encrypted value still looks like a card number, a Social Security number, or an email address, so it slots into existing systems without schema changes or application rewrites.
This makes FPE especially useful for protecting Personally Identifiable Information (PII), credit card numbers (PANs), Social Security numbers, and similar structured fields, including in legacy software that cannot handle long or oddly formatted strings. It is a valid, NIST-standardized choice for meeting encryption requirements under standards like PCI DSS.
How Does FPE Work?
FPE is built on the AES block cipher, but applied in a special way so the output stays within the same set of characters and length as the input. The essential pieces:
- A defined alphabet (radix): You specify the set of allowed symbols, for example digits 0 to 9 (radix 10), hexadecimal, or full alphanumeric. The ciphertext is drawn from that same alphabet, which is what preserves the format.
- A Feistel network: FPE modes use multiple rounds of a Feistel function: the input is split into two halves, each round transforms one half using AES and the key, and the halves are combined and swapped. FF1 uses 10 rounds; FF3-1 uses 8. This scrambles the value while keeping it in range.
- A key and a tweak: Like all encryption, FPE uses a secret key. It also uses a ‘tweak’, a non-secret value (such as a field or record identifier) that varies the encryption so identical inputs can map to different outputs in different contexts, improving security for small data domains.
Because it is reversible, the exact same key and tweak decrypt the value back to the original. This is a key difference from hashing or tokenization: FPE is true, reversible encryption.
FPE Modes: FF1, FF3, and FF3-1 (NIST SP 800-38G)
NIST standardized FPE in Special Publication 800-38G, which defines the approved modes. Their history matters:
- FF1: The most widely used and most flexible mode, using 10 Feistel rounds. It supports a wide range of input lengths and alphabets and remains a NIST-approved method.
- FF2: Proposed but never approved by NIST, so it is not used in compliant implementations.
- FF3 and FF3-1: FF3 (8 rounds) was originally approved, but in 2017 cryptographers found an attack showing it did not reach its claimed 128-bit security. NIST revised it to FF3-1 in 2019, adjusting parameters to close the weakness. Current implementations use FF3-1, not the original FF3.
Collectively these Feistel-based methods are known as the FFX construction. The FF3 episode is a useful reminder that FPE modes are more delicate than standard AES encryption, which is exactly why using vetted, current, NIST-approved modes (FF1 or FF3-1) matters.
Is FPE Weaker Than AES?
It is more accurate to say FPE is AES used in a constrained way, rather than ‘weaker than AES’. FF1 and FF3-1 are built on the AES cipher and are considered secure when implemented with current, NIST-approved parameters. The genuine caveats are structural: encrypting a very small domain (say, a short numeric field) inherently offers fewer possible outputs, and FPE’s specialized modes have proven trickier to get right than plain AES, as the FF3 revision showed. Used correctly with FF1 or FF3-1 and a proper tweak, FPE provides strong, standards-based protection; it simply trades some of AES’s generality for the ability to preserve format.
FPE vs Tokenization
FPE is often compared with tokenization, since both protect structured data like card numbers while keeping a usable format. The difference is fundamental:
| Aspect | Format Preserving Encryption | Tokenization |
|---|---|---|
| Method | Reversible encryption with a key (AES-based) | Substitutes data with an unrelated token |
| Reversibility | Decrypts back with the key and tweak | Detokenized by looking up a vault or mapping |
| Data relationship | Ciphertext is mathematically derived from the input | Token has no mathematical relationship to the value |
| Storage | No vault needed; key management required | Usually requires a token vault or mapping |
| Standard | NIST SP 800-38G (FF1, FF3-1) | No single algorithm standard; PCI guidance applies |
| Best for | Encrypting many fields at scale without a vault | Removing sensitive data from scope entirely |
In short, FPE keeps the data (encrypted) and needs strong key management, while tokenization replaces the data with a stand-in tracked separately. Many organizations use both, depending on whether they need reversible protection at scale or want to pull sensitive data out of an environment’s compliance scope.
FPE in the Cloud
Several vendors and platforms offer FPE. Among the major cloud providers, Google Cloud Platform (GCP) exposes FPE through its Data Loss Prevention (DLP) API, supporting FF1 and FF3-1. To use it, you specify the alphabet (for example NUMERIC for 0 to 9, HEXADECIMAL, UPPER_CASE_ALPHA_NUMERIC, or ALPHA_NUMERIC) or a numeric radix, so the encrypted output stays within the intended character set. For unstructured data, GCP can wrap the ciphertext in a surrogate annotation that labels the encrypted value so it can be found and reversed later. Third-party vendors such as Comforte, HashiCorp, and Futurex also provide FPE capabilities.
Is FPE Quantum-Safe? The 2026 Outlook
FPE inherits its quantum posture from AES, because FF1 and FF3-1 are built on the AES cipher. As a symmetric construction, FPE is not threatened by Shor’s algorithm, which breaks public-key algorithms like RSA and ECC but does not apply to symmetric encryption. The only relevant quantum attack is Grover’s algorithm, which halves effective key strength, so FPE built on AES-256 retains a strong security margin against future quantum computers. The important point is that FPE’s real security considerations, choosing FF1 or FF3-1, handling small domains carefully, and managing keys and tweaks well, are classical concerns, not quantum ones. The urgent post-quantum migration (where NIST finalized ML-KEM, ML-DSA, and SLH-DSA in 2024 and plans to retire RSA and ECC by 2030 to 2035) is about public-key cryptography. FPE, like AES, remains quantum-resistant when built on a strong key size.
How Encryption Consulting Helps
Deciding when to use FPE, tokenization, or standard encryption, and implementing it with sound key management, is exactly the kind of work Encryption Consulting’s Encryption Advisory Services support. We assess your sensitive data flows, recommend the right protection method for each use case, and design NIST-aligned, compliant implementations. Through our Cloud Data Lake Protection offerings, including Bucket Protector and Cloud Data Protector, we apply FPE to data in Google Cloud Storage and local databases using the DLP and KMS APIs. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.
Frequently Asked Questions
What is Format Preserving Encryption (FPE)?
Format Preserving Encryption (FPE) is a method of encryption that keeps the ciphertext in the same format and length as the original data. For example, a 16-digit credit card number encrypts to a different 16-digit number, and a Social Security number stays a 9-digit value. This lets sensitive data be encrypted without breaking databases or applications that expect a specific format. FPE is standardized in NIST SP 800-38G, uses the modes FF1 and FF3-1, and is built on the AES cipher.
How does FPE work?
FPE is built on AES but applied so the output stays within the same alphabet and length as the input. You define the allowed character set (such as digits 0 to 9), and the algorithm uses a Feistel network, multiple rounds that split the value, transform each half with AES and a key, and recombine them, to scramble the data while keeping it in range. FF1 uses 10 rounds and FF3-1 uses 8. A secret key and a non-secret ‘tweak’ control the encryption, and the same key and tweak reverse it.
Is FPE secure?
Yes, when implemented with current NIST-approved modes (FF1 or FF3-1) and proper key management. FPE is built on AES and is standardized in NIST SP 800-38G. It is worth knowing that the original FF3 mode was found in 2017 to fall short of its claimed security and was revised to FF3-1 in 2019, so implementations should use FF1 or FF3-1, not the original FF3. Very small data domains also offer fewer possible outputs, which the use of a tweak helps address.
What is the difference between FPE and tokenization?
Both protect structured data like card numbers while preserving a usable format, but they work differently. FPE is reversible encryption: the ciphertext is mathematically derived from the input using a key, and the same key decrypts it, with no vault needed. Tokenization replaces the data with an unrelated token that has no mathematical relationship to the original, and the mapping is tracked in a token vault. FPE is well suited to encrypting many fields at scale; tokenization is often used to remove sensitive data from a system’s compliance scope entirely.
What is NIST SP 800-38G?
NIST Special Publication 800-38G is the standard that defines Format Preserving Encryption for U.S. federal use and broader industry adoption. It specifies the approved FPE modes built on AES, namely FF1 and FF3-1. (A proposed FF2 mode was never approved, and the original FF3 was revised to FF3-1 after a cryptanalytic weakness was found.) Using a NIST-approved FPE mode is important for both security and for compliance with standards that reference NIST cryptography.
Is FPE quantum-safe?
Largely, yes. Because FPE (FF1 and FF3-1) is built on the AES cipher and is symmetric, it is not threatened by Shor’s algorithm, which breaks public-key algorithms like RSA and ECC. The only relevant quantum attack is Grover’s algorithm, which halves effective key strength, so FPE built on AES-256 keeps a strong margin against quantum computers. FPE’s real security considerations, mode choice and key management, are classical, not quantum. The post-quantum transition mainly concerns public-key cryptography.
Protect Structured Data the Right Way
Whether FPE, tokenization, or standard encryption is right depends on your data and systems. Explore Encryption Consulting’s Encryption Advisory Services to choose the right approach and implement it with strong, compliant key management.