I'm curious about an algorithm that would be good for the following scenario:
- 32-bit "plaintext" input, taken from a counter
- 32 or 64-bit "ciphertext" output
- It should be possible to decrypt the output with the key (and possibly a few other hidden parameters, like an offset and current counter), and return the original 32-bit counter value
- A user never observes the input, but may receive any number of outputs, possibly sequential. Even so, they should not be able to know which indices they have.
- It should be difficult to guess other outputs that correspond to valid counter values.
My untrained intuition is that since the key and outputs are larger than the input space, it should be fairly easy to have "good" results, at least for the first few outputs. However, it also seems logical that with enough samples the key and indices could be computed easily, but I expect most instances to use less than 100 values.
My questions are:
- Are there any existing algorithms that work for this scenario?
- How hard would it be to crack? I.e., compute values that decrypt to valid indices.
- How much does the possession of more samples affect the efficiency of cracking it?
What's wrong with a naive approach like:
u64 output = input repeat 64x output = ((output ^ key) + key) rotate-left 37
Assuming addition wraps around 64bit integer boundaries. It seems as though it would thoroughly mix the random key with a single input, but possessing more than one output could quickly increase the information an attacker possesses, though I wouldn't know how. Obviously it's going to be broken, I'm just trying to learn.
- Would using a key-dependent value for the left-rotation, like
(((key & 0xFFFE)+1) * 37)be better? How much does it help and why?
- What approaches, resources, etc. would you use to both analyze the algorithm, and design a better one?