Format-Preserving Encryption
Format-Preserving Encryption (FPE) encrypts a value while preserving its exact format — an SSN like 123-12-1234 encrypts to another value that looks like a valid SSN, for example 812-01-2345. FPE uses the FF3-1 algorithm and preserves the length and character set of the original value.
On Snowflake, encryption and decryption happen inside your Snowflake environment through user-defined functions (UDFs). ALTR manages the encryption keys but never accesses plaintext or ciphertext. FPE is also available over the Snowflake REST API, for encrypting data before it’s loaded into Snowflake.
Because FPE preserves format and can be applied deterministically, encrypted values maintain referential integrity — for example, joining on encrypted SSNs or training a machine learning model on encrypted identifiers without accessing the raw values.
Encryption Mechanism
Section titled “Encryption Mechanism”FPE uses the FF3-1 algorithm, which requires 3 inputs: the plaintext value, an encryption key, and a tweak.
FPE supports VARCHAR data in 3 alphabets:
| Alphabet | Characters | Minimum length |
|---|---|---|
| Alphanumeric | a-z, A-Z, 0-9 | 4 characters |
| Alphabetic | a-z, A-Z | 4 characters |
| Numeric | 0-9 | 6 characters |
Native integer and numeric column types aren’t supported — Snowflake drops leading zeros on those types, which would corrupt the encrypted value. Numeric data must be stored as, or cast to, VARCHAR before FPE encryption.
Values below an alphabet’s minimum length can be padded before encryption. Padding is disabled by default. Non-deterministic padding preserves security but breaks determinism — the same input produces different encrypted outputs, which prevents joins, lookups, and deduplication on the encrypted value. Deterministic padding maintains referential integrity — the same input produces the same encrypted output — but compromises the security of the FF3-1 algorithm and should not be used for security-sensitive data.
Enabling padding requires a Change Request and a signed legal agreement. Contact ALTR to enable padding for your account.
Key Management
Section titled “Key Management”FPE uses a two-layer key hierarchy: a data encryption key (DEK) that encrypts and decrypts the data, and a key encryption key (KEK) that encrypts the DEK. Rotating a key rotates the KEK, not the DEK — the DEK is re-encrypted with the new KEK, so existing encrypted data doesn’t need to be re-encrypted.
A tweak is a value that modifies the encryption output, so the same key produces different ciphertext for different tweaks. Best practice is a 1:1 mapping between columns (or tags) and key/tweak pairs, so the same value in different columns encrypts to different ciphertext.
Recommended key rotation cadence is every 3 to 6 months. A cooldown period applies between rotations of the same key.
Bring Your Own Key (BYOK)
Section titled “Bring Your Own Key (BYOK)”Customers can manage their own key encryption key (KEK) in place of ALTR’s managed KEK, giving them control over the encryption key hierarchy.
Decryption Methods
Section titled “Decryption Methods”Decryption is available via policy, UDF, and API (including the Snowflake REST API).
- Policy-based. Decryption happens automatically at query time, evaluated against a masking policy with detokenization. Authorized roles see the decrypted value; other roles see the encrypted, format-preserved value. Encrypted values are returned by default — decryption requires explicit policy configuration.
- UDF-based. Ad hoc decryption for users granted direct access to the decryption function, independent of the policy-based path.
- API-based. Decrypt values over the Snowflake REST API. API access enables integration with other tools, but doesn’t cover masking-with-decryption or tokenization — those are available only through the policy-based and UDF-based paths.
Both decryption paths resolve to the same underlying access outcome as tokenization’s three-level model — a role sees the encrypted value, a masked version, or the decrypted value, depending on the policy configured for it.
For the Snowflake-specific mechanics of connecting a column or tag for FPE — protection types, native vs. external-function masking, and the masking policy that ties encryption to access control — see Data Masking on Snowflake.