Suppose we have a web service operation like:
GetComments(encryptedDiscussionID) // returns list of comments
Where encryptedDiscussionID is the encrypted version of the actual discussionID in the database. The encryption is done on the server using a key which is private to the server.
The client has already been sent the encryptedDiscussionID.
My question is: How 'long' should the encryptedDiscussionID be, to ensure it is secure / not guessable?
That depends on how many guesses you will allow and what the chance of someone succeeding in guessing a valid encryptedDiscussionID can be. Also you need to take into account how many of such discussionIDs you will have.
If you have 1000 of these IDs and you have 10 000 possible discussion IDs it will only take on average 10 attempts to guess such an ID.
If you take alphanumeric encryptedDiscussionIDs the amount of possible IDs is equal to 26^length.
So if you take discussionIDs with a length of 10 characters you will have 1,41*10^12 possible IDs. If you have 1000 valid IDs in you database then it will take on average 1,41*10^9 attempts to guess a valid ID. I'm guessing you would be able to detect such an amount of attempts. But since adding extra characters to the encryptedDiscussionID I would make it even longer.
If you can provide more details it's possible to give a more detailed anwser.
How are you doing the server-side lookup of these encryptedDiscussionIDs. I assume you don't calculate these every time someone issues a query? Do you store them as well?
Don't forget that if someone can see (-> passive network attacker, sniffing) these encryptedDiscussionIDs on the network he will still be able to view the list of comments.
