c# format preserving encryption for integers

Question

I have a requirement for generating numeric codes that will be used as redemption codes for vouchers or similar. The requirement is that the codes are numeric and relatively short for speed on data entry for till operators. Around 6 characters long and numeric. We know that's a small number so we have a process in place so that the codes can expire and be re-used.

We started off by just using a sequential integer generator which is working well in terms of generating a unique code. The issue with this is that the codes generated are sequential so predictable which means customers could guess codes that we generate and redeem a voucher not meant for them.

I've been reading up on Format Preserving Encryption which seems like it might work well for us. We don't need to decrypt the code back at any point as the code itself is arbitrary we just need to ensure it's not predictable (by everyday people). It's not crucial for security it's just to keep honest people honest.

There are various ciphers referenced in the wikipedia article but I have very basic cryptographic and mathematical skills and am not capable of writing my own code to achieve this based on the ciphers.

I guess my question is, does anyone know of a c# implementation of this that will encrypt an integer into another integer and maintain the same length?

FPE seems to be used well for encrypting a 16 digit credit card number into another 16 digit number. We need the same sort of thing but not necessarily fixed to a length but as long is the plain values length matches the encrypted values length.

So the following four integers would be encrypted

from 123456 123457 123458 123459

to something non-sequential like this

521482 265012 961450 346582

I'm open to any other suggestions to achieve this FPE just seemed like a good option.

EDIT

Thanks for the suggestions around just generating a unique code and storing them and checking for duplicates. for now we've avoided doing this because we don't want to have to check storage when we generate. This is why we use a sequential integer generator so we don't need to check if the code is unique or not. I'll re-investigate doing this but for now still looking for ways to avoid having to go to storage each time we generate a code.

Answer 1

I wonder if this will not be off base also, but let me give it a try. This solution will require no storage but will require processing power (a tiny amount, but it would not be pencil-and-paper easy). It is essentially a homemade PRNG but may have characteristics more suitable to what you want to do than the built-in ones do.

To make your number generator, make a polynomial with prime coefficients and a prime modulus. For example, let X represent the Nth voucher you issed. Then:

Voucher Number = (23x^4+19x^3+5x^2+29x+3)%65537. This is of course just an example; you could use any number of terms, any primes you want for the coefficients, and you can make the modulus as large as you like. In fact, the modulus does not need to be prime at all. It only sets the maximum voucher number. Having the coefficients be prime helps cut down on collisions.

In this case, vouchers #100, 101, and 102 would have numbers 26158, 12076, and 6949, respectively. Consider it a sort of toy encryption where the coefficients are your key. Not super secure, but nothing with an output space as small as you are asking for would be secure against a strong adversary. But this should stop the everyday fraudster.

To confirm a valid voucher would take the computer (but calculation only, not storage). It would iterate through a few thousand or tens of thousands of input X looking for the output Y that matches the voucher presented to you. When it found the match, it could signal a valid voucher.

Alternatively, you could issue the vouchers with the serial number and the calculation concatenated together, like a value and checksum. Then you could run the calculation on the value by hand using your secret coefficients to confirm validity.

As long as you do not reveal the coefficients to anyone, it is very hard to identify a pattern in the outputs. I am not sure if this is even close to as secure as what you were looking for, but posting the idea just in case.

I miscalculated the output for 100 (did it by hand and failed). Corrected it just now. Let me add some code to illustrate how I'd check for a valid voucher:

using System;
using System.Numerics;

namespace Vouchers
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Enter voucher number: ");
            BigInteger input = BigInteger.Parse(Console.ReadLine());
            for (BigInteger i = 0;i<10000000;i++)
            {
                BigInteger testValue = (23 * i * i * i * i + 19 * i * i * i + 5 * i * i + 29 * i + 3) % 65537;
                if(testValue==input)
                {
                    Console.WriteLine("That is voucher # " + i.ToString());
                    break;
                }
                if (i == 100) Console.WriteLine(testValue);
            }
            Console.ReadKey();
        }
    }
}

Answer 2

One option is to build an in-place random permutation of the numbers. Consider this code:

private static readonly Random random = new Random((int)DateTime.UtcNow.Ticks);

private static int GetRandomPermutation(int input)
{
    char[] chars = input.ToString().ToCharArray();
    for (int i = 0; i < chars.Length; i++ )
    {
        int j = random.Next(chars.Length);
        if (j != i)
        {
            char temp = chars[i];
            chars[i] = chars[j];
            chars[j] = temp;
        }
    }
    return int.Parse(new string(chars));
}

You mentioned running into performance issues with some other techniques. This method does a lot of work, so it may not meet your performance requirements. It's a neat academic exercise, anyway.

Answer 3

Thanks for the help from the comments to my original post on this from Blogbeard and lc. It Turns out we needed to hit storage when generating the codes anyway so this meant implementing a PRNG was a better option for us rather than messing around with encryption.

This is what we ended up doing

1. Continue to use our sequential number generator to generate integers
2. Create an instance of C# Random class (a PRNG) using the sequential number as a seed.
3. Generate a random number within the range of the minimum and maximum number we want.
4. Check for duplicates and regenerate until we find a unique one

Turns out using c# random with a seed makes the random numbers actually quite predictable when using the sequential number as a seed for each generation.

For example with a range between 1 and 999999 using a sequential seed I tested generating 500000 values without a single collision.