You're Probably Using FPE Wrong

The talk opens with an auditor's quiz: two columns, one plaintext and one format-preserving ciphertext, and the point that placing them side by side leaks everything. The speaker frames the technique as a fit for mainframe, banking, and healthcare systems where field length and character set cannot change. The core parameters are the alphabet, radix, domain, key, and tweak, and the FF1 Feistel rounds are sketched. Only FF1 is NIST-approved, and open-source FF3-1 code is described as unsafe for production.

The middle of the talk covers rollout failures. Small domains such as states, genders, or PINs are easy to brute-force once an oracle can validate guesses, so encrypting low-entropy fields gains little. Determinism enables joins and analytics but exposes frequency patterns, and a tweak does not add entropy. Other problems include codebooks built from plaintext beside ciphertext, vendors that encode characters differently, and no authentication, so a wrong key returns plausible output silently. Key rotation changes ciphertext too, so keys and configuration must travel with the data.

The speaker suggests widening the alphabet to alphanumeric so encrypted values are visibly distinct, which also makes wrong-key decryption easier to spot. FPE fits large domains such as card and Social Security numbers in locked schemas. Where schemas can change, authenticated encryption, tokenization, or masking are often better.