(1) Create a server only known stored “salt”
(2) Concatenate “salt” + ID (e.g. first 8 bytes are salt, next 4 bytes are id)
(3) Encrypt these 12 bytes using AES (possibly with “salt” as the “password”… not sure if this compromises anything)
(4) Send this to browser
(5) Receive data from browser
(6) Unencrypt data using “password”
(7) Verify “salt”
(8) Trust ID

Now, I’m not sure how much the “password”‘s integrity is compromised by a significant portion of the encrypted data being unchanged for each ID. My guess is very very little (because otherwise AES would be fundamentally flawed.. e.g. the password determined for a file just by knowing that it starts with a known header).

Of course you have to keep the “salt” and “password” secret. But this is required in your scheme as well.

This should allow the int to be both trusted, unknown, and unable to be tampered with.

All symmetric-key encryption approaches provide reversibility, but I did not find any that provided tamper-resistance, at least not resulting in a small, compact encrypted ID.

For what it’s worth, I’m in the process of evaluating other base algorithms, so I’m wide open to suggestions.

Encrypting 4 bytes (Int32) with a 64-bit block size should spit out a result that is about 11 characters (after using base64, please check my math). This seems like a lot of re-inventing the wheel… Is computing these 3 hashes faster than a single AES encryption? I haven’t done the benchmarking myself, but my gut says that even if it is, the benefit likely doesn’t outweigh the use of a standardized encryption scheme.

but it generates the ” : ” character in the encoded string that cannot be in a url because it is used for the authentication. For example encoding the int 1689 with CRYPT_SALT “some random string” generates “NgvsvpI62eNcmhduKmX:w” (without “). This string pasted in a browser will fail due to “:” char.

Waht if I want to support a wider range of integers? (> 2^31-1)

Thanks.