# Format preserving numbers within an offset range?

Very short question.

Is it possible to encrypt a sequence of numbers with FPE in a range 10 000 to n where the possible encrypted values are offset and can only fall within the range 10 000 to n?

Eg. A sequence number with a maximum of 10 digits will be zero padded (0000 0532 12) and encrypted into the IAN part of a PAN number (Equivalent digit size). Any sequence number larger than 9999 should not be encrypted to have an IAN with six leading zeros xxxx xxxx 0000 0020 31y.

Is it possible to encrypt a sequence of numbers with FPE in a range 10 000 to n where the possible encrypted values are offset and can only fall within the range 10 000 to n?

Easily; here's a straight-forward 3 step process to encrypt a value $$x \in [10000, n]$$:

• Subtract 10000 from n

• Encrypt it using an FPE method that handles a range $$[0, n-10000]$$. This may involve selecting an appropriate base, and possibly reencrypting the ciphertext if it falls outside the range

• Add 10000 to the result

The corresponding decryption process should be obvious...

And, the standard way to handle plaintexts/ciphertexts in a range $$[0, x]$$ with a base $$b^e > x$$ is:

• Express the plaintext as $$e$$ base-$$b$$ digits (using a base conversion routine)

• Encrypt the plaintext using the key

• If the result happens to be $$> x$$, then reencrypt that result with the same key (and repeat until the result is in range)

• Convert that result into the ciphertext (using another base conversion routine)

This takes variable time, however it doesn't leak any information (as the attacker cannot deduce anything from an intermediate result being out of range). And, it will always halt (as FPE encryption is a bijection, the result of multiple encryptions will be a cycle, and so as long as you start with a value within the range, you'll end up with a value within the range)

• Thanks! I actually came to the conclusion of re-encrypting the output if it's outside the range just minutes before checking your response XD Just for documentation. First example does make sense as well. The obvious problems are. Firstly finding a base that is close enough to the size of the of the range and secondly encrypting the output again. Simpler to just ditch the 3 step process. May 4, 2022 at 14:33
• @spurtin: well, yes, if $n$ is a nice value (say, a power of 2 or even better, of 256), and $n \ggg 10000$, then just rejecting the values $[0, 9999]$ makes sense May 4, 2022 at 14:40