<\/p>\n
FORMAT-PRESERVING ENCRYPTION<\/p>\n
Legacy systems often require a value to remain decimal, retain its length and pass through fields designed for an account number or identifier. Conventional encryption produces binary ciphertext that does not fit.<\/p>\n
Format-preserving encryption maps a value to another value in the same finite domain. A sixteen-digit input becomes a sixteen-digit ciphertext. An alphabetic code can remain alphabetic.<\/p>\n
Compatibility improves because the ciphertext still looks like the original data type. That same resemblance preserves structural information and can invite assumptions the encryption does not support.<\/p>\n
An FPE construction operates over strings of a defined radix and length. The set of all permitted strings is the cryptographic domain.<\/p>\n
A decimal field of length sixteen has a much larger domain than a four-digit branch code. Security analysis must consider that size, not only the AES key length used inside the mode.<\/p>\n
In a small domain, an attacker can enumerate candidate plaintexts, observe known pairs or build frequency information. A 256-bit key does not turn ten thousand possible values into a 256-bit search problem.<\/p>\n
Preserving decimal characters and length does not guarantee that the ciphertext passes a Luhn check, refers to an assigned issuer range or satisfies an application’s internal validation.<\/p>\n
If a system requires those constraints, the domain may need to exclude invalid values or the application may need to recompute selected check digits outside encryption.<\/p>\n
Every excluded or reconstructed component leaks additional structure. The implementation must define exactly which positions are encrypted and which remain derived or visible.<\/p>\n
FF1 accepts a tweak in addition to the key and plaintext. The tweak need not be secret. It changes the permutation selected under the key.<\/p>\n
A well-designed tweak can separate tenants, fields, tables or record contexts so that the same plaintext does not always map to the same ciphertext everywhere.<\/p>\n
The tweak must be stable when decryption is required and encoded unambiguously. Deriving it from an unstable database position can make data unrecoverable after migration. Reusing one empty tweak globally can create unnecessary cross-context correlation.<\/p>\n
For a fixed key and tweak, format-preserving encryption is deterministic. Equal plaintext values produce equal ciphertext values.<\/p>\n
This can support database joins and duplicate detection, which may be the operational reason for choosing it. It also exposes frequency and equality patterns to anyone who can observe the ciphertext column.<\/p>\n
Changing the tweak per record hides equality but removes straightforward lookup and requires the tweak to travel with the ciphertext. There is no setting that simultaneously provides deterministic search and hides equality.<\/p>\n
FF1 is an encryption mode, not an authenticated-encryption mode. A database modification produces another value in the same format. Decryption may yield plausible but incorrect plaintext.<\/p>\n
An application that needs tamper detection requires a separate authentication tag, protected record context or authenticated container. Storing a tag may be exactly what the legacy schema was unable to accommodate.<\/p>\n
That tension should be visible in the architecture. Preserving the field format can solve storage compatibility while leaving integrity to a wider record boundary.<\/p>\n
Tokenization replaces a sensitive value with another value and normally relies on a mapping service or vault. The token need not be the output of a reversible block-cipher construction.<\/p>\n
FPE is reversible encryption under a key and tweak. Anyone with the cryptographic capability can recover the plaintext without consulting a mapping database.<\/p>\n
The approaches have different compromise, deletion, collision and availability properties. Calling FPE tokenization because its output fits the same column hides the real trust boundary.<\/p>\n
Systems often leave a prefix visible for routing and encrypt only the remaining digits. This preserves business processing but shrinks the domain seen by each visible prefix.<\/p>\n
If the plaintext distribution within one prefix is sparse or predictable, the effective uncertainty can be far below the nominal number of encrypted digits.<\/p>\n
Domain-size analysis should be performed per visible partition, not for the entire original identifier space.<\/p>\n
Attackers may know many plaintext-ciphertext pairs from test environments, customer records or repeated processing. A secure FPE mode is designed to tolerate known plaintext without revealing the key.<\/p>\n
Known pairs can still reveal application structure, tweak reuse and equality. They can also enable codebook attacks when the actual plaintext domain is very small.<\/p>\n
Cryptographic strength and information leakage are different measurements.<\/p>\n
NIST originally standardized FF1 and FF3. Cryptanalysis of FF3 and concerns about small domains led to revisions. The 2025 second public draft of SP 800-38G Revision 1 specifies FF1, raises domain-size requirements and removes FF3 from the revised recommendation.<\/p>\n
A deployment should record the exact method and revision rather than store a generic algorithm label such as FPE-AES. Parameter constraints and approved modes have changed while the visible ciphertext format has remained the same.<\/p>\n
Because ciphertext contains no obvious algorithm metadata, the application needs another way to identify the key, method and tweak derivation used for each value.<\/p>\n
Trying several keys until one decrypts to a plausible format is unsafe because every decryption result already has that format. Version information must be authenticated outside the ciphertext or derived from an unambiguous record epoch.<\/p>\n
Bulk re-encryption also exposes plaintext inside the migration path and can disrupt deterministic indexes.<\/p>\n
Format-preserving encryption is valuable when an interface genuinely cannot carry ordinary ciphertext. It should not be the default merely because a value looks cleaner in a database.<\/p>\n
The retained alphabet, length, prefixes and equality patterns are observable properties. Integrity, versioning and key rotation need surrounding structures that the narrow field may not provide.<\/p>\n
Preserving the format preserves part of the leakage. The engineering decision is whether that leakage is an acceptable price for compatibility.<\/p>\n
Format-preserving encryption keeps ciphertext compatible with narrow legacy fields. It also keeps domain size, length, structure and often equality visible.<\/p>\n","protected":false},"author":2,"featured_media":364,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"nlabs_article_type":[],"class_list":["post-367","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-research"],"_links":{"self":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/367","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/comments?post=367"}],"version-history":[{"count":0,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/367\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media\/364"}],"wp:attachment":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media?parent=367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/categories?post=367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/tags?post=367"},{"taxonomy":"nlabs_article_type","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/nlabs_article_type?post=367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}