How to symmetrically encrypt 64bit values? 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 &amp; 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?
Are there any existing algorithms that work for this scenario?
  


Yes, actually, there are a number of 64 bit block ciphers.  The standard wisdom is that they aren't encouraged for general use, because standard block cipher modes tend to start leaking information when you get near the birthday bound (in this case, circa 30 Gbytes); however for your use case, that would not be a concern.

Here are some options:


3DES (aka TDES); this is DES applied three times with three different keys; this has the advantage of being very well studied.
Speck which has parameter sets with 64 bit block ciphers.  This has the advantage of being the fastest alternative, and was designed by people who know that they're doing, and has done through a surprising amount of cryptanalysis.
An FPE cipher (such as FF1, which can handle any arbitrary block size (including 64 bits).  This has the advantage in that they allow the option for a tweak (which is a convenient place to place the "other hidden parameters", should you decide that is an advantage).  It's slower than the alternatives; with FF1, the security comes from the underlying security of AES, plus the provable security of the Feistel structure.


Now, these take keys longer than 64 bits; the common wisdom is that a 64 bit key is just not long enough.


  
  How hard would it be to crack? I.e., compute values that decrypt to valid indices.
  


For any of the above, the only practical option an adversary would have would be to randomly guess ciphertexts, and hope to stumble on one that decrypts to a valid index.


  
  How much does the possession of more samples affect the efficiency of cracking it?
  


For any of the above, having vast quantities of samples will still make the attack infeasible.


  
  What's wrong with a naive approach like...
  


ARX ciphers (actually, any cipher, but especially ARX) are tricky to get right.  ARX ciphers in particular tend not to be great at disrupting differential and linear characteristics (which means any such design would really need to be well studied to make sure that it does).


  
  What approaches, resources, etc. would you use to both analyze the algorithm, and design a better one?
  


I'd suggest you go with a design which has already been analyzed; I list three above.