Format Preserving Encryption (FPE) – Usage on GCP

Format-Preserving Encryption (FPE) is a cipher construction that encrypts data into ciphertext of the exact same length and character set as the input, such as turning a 16-digit card number into another 16-digit number. It matters because it lets legacy schemas, validation rules, and downstream systems keep working unchanged while the underlying value is cryptographically protected. On Google Cloud, use the FF1 algorithm inside Sensitive Data Protection with a Cloud KMS-wrapped key rather than a bare key or a hand-rolled implementation.

Published: August 2020. Updated: August 2026. Reviewed by Encryption Consulting’s Cloud Data Protection Team.

For the vendor-neutral definition of Format-Preserving Encryption and how it compares to other de-identification techniques, see our Education Center article What Is Format-Preserving Encryption?. For how the wrapping key underneath FPE should be managed, see AWS KMS Vs Azure Key Vault Vs GCP KMS.

What Is Format-Preserving Encryption?

If an organization has 16-digit credit card numbers stored in a database, and every downstream system, index, and validation rule expects that field to stay exactly 16 digits, standard encryption breaks the schema, since plaintext encrypted with AES-GCM or similar produces ciphertext of a different length and character set. Format-Preserving Encryption (FPE) solves this: it encrypts plaintext of a given length and alphabet into ciphertext of the exact same length and alphabet. Encrypting the plaintext 1483920193402918 with FPE could produce an output like 1483666666662918: same 16 digits, same numeric alphabet, but cryptographically protected.

FPE is one of three pseudonymization techniques Google Cloud supports for de-identifying data through Sensitive Data Protection (formerly Cloud DLP): deterministic encryption using AES-SIV, Format-Preserving Encryption, and cryptographic hashing. All three replace sensitive values with cryptographically generated tokens using a key; this article focuses on the FPE method specifically.

How Does Format-Preserving Encryption Work on Google Cloud?

Google Cloud implements FPE through a construction called FFX, which defines two candidate methods, FF1 and FF3, for turning plaintext into format-preserving ciphertext. FF1 is the only FFX method currently approved for encryption on Google Cloud. FF2 was never finalized for publication when FFX was created, and FF3 was found to be cryptanalytically weak in a 2017 attack, after which NIST withdrew its recommendation for FF3 pending a stronger revision (FF3-1). Google Cloud’s implementation reflects that history by supporting FF1 only.

FFX builds ciphertext by running multiple rounds of a Feistel function against the plaintext, using the encryption key at each round. A Feistel function splits the plaintext into two halves, applies a keyed permutation to one half based on the other, and swaps the halves each round. FF1 uses 10 rounds of this Feistel function (FF3 used 8, part of why it proved weaker). Before encryption can start, the alphabet used to de-identify the data has to be specified one of three ways: selecting one of Google’s four predefined common character sets, specifying a radix value (2 for binary, 95 for the full printable ASCII range with numbers, upper/lowercase letters, and symbols), or supplying a custom alphabet containing the exact characters to use.

When FPE-FFX runs in Sensitive Data Protection, the resulting ciphertext can be prepended with a surrogate annotation to form a final token in the form surrogate_infotype(surrogate_length):surrogate_value. The infotype is user-defined and the surrogate value is the ciphertext itself. Re-identifying unstructured data requires the full token including its surrogate annotation; structured data (a known column in a known schema) only needs the surrogate value, since the infotype and length are already implied by the schema.

How Does Native vs. External Key Control Work for FPE?

Every FPE-FFX operation needs an AES key, and Google Cloud gives three ways to supply it, each with a different custody model.

Key-control model	How it works	Best fit
Native (raw key in request)	The base64-encoded AES key is included directly in every de-identify/re-identify API call.	Local testing only. The key is exposed in the request payload and must be excluded from logging manually.
Cloud KMS-wrapped key (BYOK-equivalent)	The AES key is encrypted by a Cloud KMS key and only the wrapped ciphertext is stored/transmitted; Sensitive Data Protection calls Cloud KMS to unwrap it per operation.	Production. IAM governs who can invoke the unwrap, and every unwrap is captured in Cloud Audit Logs.
External/HYOK-equivalent (Cloud EKM)	The Cloud KMS key wrapping the AES key is itself hosted by an external key manager through Cloud External Key Manager, so Google never holds usable key material at rest.	Regulated data where a contract or regulator requires the cloud provider to never possess the key, accepting the added latency of an external key-manager round trip on every operation.

The wrapped-key model should be the default for any FPE deployment handling real customer data. It adds IAM-governed access control and a full audit trail that a bare key cannot provide, and it is the pattern Google’s own documentation recommends for production tokenization and FPE workloads.

How Should IAM Govern Who Can Tokenize and Re-identify?

FPE is reversible by design, which is exactly what makes it useful (a payments system needs the real card number back eventually) and exactly why access control matters more here than for one-way hashing. Structure IAM around the operation, not just the data:

1. Grant the application layer that only needs to store a tokenized value permission to call de-identify, but not re-identify.
2. Grant re-identify permission only to the specific service accounts that legitimately need the original value back (a payment processor, a fraud-review workflow), never to a broad analytics role.
3. Give the Cloud KMS wrapping key’s cryptoKeyEncrypterDecrypter role only to the DLP service account, never directly to a human identity.
4. Separate the identity that manages the inspect/de-identify templates from the identity that consumes tokenized output, so template changes are auditable independent of data access.
5. Review re-identify grants on the same cadence as production database access reviews, since a stale re-identify grant is functionally equivalent to standing access to the plaintext.

How Should You Handle Key Rotation for FPE?

Rotating the Cloud KMS key that wraps an FPE AES key creates a new key version, but Google Cloud is explicit that rotation “doesn’t re-encrypt your data and doesn’t disable or delete previous key versions.” For FPE specifically, this means every value tokenized under the old wrapping-key version still needs that exact key version available to be re-identified later. Destroy a key version before every dependent FPE value has been re-encrypted under the new version, and that data becomes permanently unrecoverable, by design.

A safe pattern: rotate the Cloud KMS wrapping key on a defined schedule (there is no fixed Cloud KMS minimum or maximum rotation interval, but a common baseline is 90 days for symmetric keys), decrypt and re-tokenize existing FPE values under the new key version in a background batch job, and only schedule destruction of the retired key version once that batch job confirms zero remaining dependents. Cloud KMS’s default scheduled-destruction window is 30 days, which gives a reasonable buffer to catch any values a batch job missed.

What Should You Log for an FPE Deployment?

• Every re-identify call, with caller identity and the specific field/record referenced, since re-identify is the operation that actually exposes plaintext.
• Cloud KMS unwrap operations against the wrapping key, captured automatically through Cloud Audit Logs.
• Template changes to the inspect/de-identify configuration that defines which fields get FPE applied and with what alphabet.
• Key-version lifecycle events (rotation, scheduled destruction, cancellation), so a security admin can correlate a “value can no longer be re-identified” incident back to a specific key event.

What Does FPE Cost on Google Cloud?

FPE itself is billed as a Sensitive Data Protection transformation operation, under the same content-method or storage-job pricing that covers tokenization generally: directionally, content-method transformation runs roughly $2.00/GB after a 1 GB/month free tier, up to 1 TB, with a lower per-GB rate above that (confirm current rates against Google’s pricing page, since Sensitive Data Protection pricing is tiered and can change). The Cloud KMS wrapping key adds a separate, usage-based charge for each wrap/unwrap operation, which scales with how many FPE operations run, not with the volume of data scanned.

The cost detail most teams miss: because FPE is reversible, a workload that both tokenizes on write and re-identifies on read (a payments system, for example) pays the Cloud KMS operation cost twice per record lifecycle, not once. Model that doubled operation count before comparing FPE’s total cost against a one-way hashing or masking approach that never needs re-identification.

What Does Multi-Cloud FPE Architecture Look Like?

FPE support is not uniform across the major clouds. Google Cloud has FF1 built directly into Sensitive Data Protection; AWS has no native FPE primitive in AWS KMS and typically requires a third-party library or a hardware security module vendor’s FPE implementation running on top of AWS CloudHSM; Azure similarly has no native FPE service and relies on partner solutions or Always Encrypted’s deterministic encryption (which is not the same construction as FPE) for schema-preserving protection. A multi-cloud data platform that needs consistent format-preserving tokenization across all three clouds generally has to standardize on a third-party or self-hosted FPE library rather than each cloud’s own native tooling, and wrap that library’s key material in each cloud’s native KMS (Cloud KMS, AWS KMS, Azure Key Vault) for consistent access control and audit.

See our comparison of AWS KMS, Azure Key Vault, and GCP KMS for how the native key-management layer underneath any FPE implementation differs across the three providers.

What Are the Limitations of Format-Preserving Encryption?

• FPE preserves length and alphabet, not semantic validity. A downstream system enforcing a Luhn checksum on card numbers, or a date-range check, may reject FPE ciphertext unless the transform is built to preserve that specific property.
• Because FPE is reversible, it does not meet requirements that call for irreversible de-identification or anonymization; use hashing or generalization instead when reversibility itself is the compliance problem.
• Only FF1 is currently approved; teams should not implement or rely on FF3 for new work given its known cryptanalytic weakness.
• Key-version lifecycle is entirely the customer’s responsibility; Google does not automatically re-encrypt FPE values when a wrapping key rotates.

Decision Checklist: Deploying FPE on Google Cloud

1. Confirm the field genuinely needs format preservation (a downstream schema or validation dependency), not just de-identification generally.
2. Use FF1 exclusively; do not build new workflows on FF3.
3. Wrap the AES key in Cloud KMS and grant cryptoKeyEncrypterDecrypter only to the service account that calls Sensitive Data Protection.
4. Separate de-identify and re-identify IAM grants, and review re-identify access on the same cadence as production data access.
5. Write the key-rotation-and-re-tokenization runbook before the first production value is tokenized.

What Would Encryption Consulting Recommend?

FPE deployments tend to work fine on day one and become a liability at the first key rotation, because the re-tokenization runbook was never built. Encryption Consulting’s Cloud Data Protection advisory service designs the FPE key lifecycle, the de-identify/re-identify IAM split, and the rotation runbook together, and our HSM-as-a-Service offering gives the Cloud KMS wrapping key hardware-backed custody where FIPS 140-3 assurance is required.

Frequently Asked Questions

What is the difference between FPE and tokenization?

Tokenization is the general concept of replacing a sensitive value with a substitute token; FPE is one specific cryptographic technique for generating that substitute, one that guarantees the output has the same length and character set as the input. Google Cloud’s Sensitive Data Protection offers FPE alongside two other tokenization methods (deterministic AES-SIV encryption and cryptographic hashing).

Why does Google Cloud only support FF1 and not FF3?

FF3 was shown to be cryptanalytically weak in a 2017 attack, after which its security margin was considered insufficient for production use. FF1 uses more Feistel rounds (10 versus FF3’s 8) and remains the approved method.

Can FPE ciphertext be used in a database index or unique constraint?

Yes for deterministic FPE, since the same plaintext under the same key and alphabet always produces the same ciphertext, which is exactly what makes it usable as an index or join key without decrypting first, unlike randomized encryption.

Does rotating the Cloud KMS wrapping key break existing FPE data?

Not immediately. Rotation creates a new key version without deleting old ones, so existing FPE ciphertext remains re-identifiable as long as its original key version still exists. The risk only appears if that old version is destroyed before a re-tokenization pass runs.

Is FPE available natively on AWS or Azure like it is on Google Cloud?

No. Neither AWS KMS nor Azure Key Vault ships a native FPE primitive comparable to Google Cloud’s FF1 implementation inside Sensitive Data Protection; most AWS and Azure deployments rely on a third-party library or hardware security module vendor’s FPE implementation instead.

Need help designing the key lifecycle behind an FPE rollout, not just the encryption call itself? Talk to Encryption Consulting’s Cloud Data Protection team.