Question

Will any encryption scheme safely allow me to encrypt the same integer repeatedly, with different random material prepended each time? It seems like the kind of operation that might get me in hot water.

I want to prevent spidering of items at my web application, but still have persistent item IDs/URLs so content links don’t expire over time. My security requirements aren’t really high for this, but I’d rather not do something totally moronic that obviously compromises the secret.

// performed on each ID before transmitting item search results to the client
public int64 encryptWithRandomPadding(int32 id) {
    int32 randomPadding = getNextRandomInt32();
    return encrypt(((int64)randomPadding << 32) + id), SECRET);
}

// performed on an encrypted/padded ID for which the client requests details
public int32 decryptAndRemoveRandomPadding(int64 idToDecrypt) {
    int64 idWithPadding = decrypt(idToDecrypt, SECRET);
    return (int32)idWithPadding;
}

static readonly string SECRET = "thesecret";

Generated IDs/URLs are permanent, the encrypted IDs are sparsely populated (less than 1 in uint32.Max are unique, and I could add another constant padding to reduce the likelyhood of a guess existing), and the client may run the same search and get the same results with different representative IDs each time. I think it meets my requirements, unless there’s a blatant cryptographic issue.

Example:

 encrypt(rndA + item1)   -> tokenA
 encrypt(rndB + item1)   -> tokenB
 encrypt(rndC + item2)   -> tokenC
 encrypt(rndD + item175) -> tokenD

Here, there is no way to identify that tokenA and tokenB both point to identical items; this prevents a spider from removing duplicate search results without retrieving them (while retrieving increments the usage meter). Additionally, item2 may not exist.

Knowing that re-running a search will return the same int32 padded multiple ways with the same secret, can I do this safely with any popular crypto algorithms? Thanks, crypto experts!

note: this is a follow-up to a question that didn’t work out as I’d hoped: Encrypt integer with a secret and shared salt

Answer 1

If your encryption is secure, then random padding makes cracking neither easier nor harder. For a message this short, a single block long, either everything is compromised or nothing is. Even with a stream cipher, you’d still need the key to get any further; the point of good encryption is that you don’t need extra randomness. Zero padding or other known messages at least a block long at the beginning are obviously to be avoided if possible, but that’s not the issue here. It’s pure noise, and once someone discovered that, they’d just skip ahead and start cracking from there.

Now, in a stream cipher, you can add all the randomness in the beginning and the later bytes will still be the same with the same key, don’t forget that. This only actually does anything at all for a block cipher, otherwise you’d have to xor the random bits into the real value to get any use out of it.

However, you might be better off using a MAC as padding: with proper encryption, the encrypted mac won’t give any information away, but it looks semi-randomish and you can use it to verify that there were no errors or malicious attacks during decryption. Any hash function you like can create the MAC, even a simple CRC-32, without giving anything away after encryption.

(A cryptographer might find a way to shave a bit or two off due to the relatedness, will tons of plaintexts if they knew beforehand how they were related, but that’s still far beyond practicality.)

As you asked before, you can safely throw in an unecrypted salt in front of every message; a salt can only compromise an encrypted value if the implementation is broken or the key compromised, as long as the salt is properly mixed into the key, particularly if you can mix it into the expanded key schedule before decryption. Modern hash algorithms with lots of bits are really good at that, but even mixing into a regular input key will always have the same security as the key alone.