How do I know if my encryption algorithm is strong enough?
When the question is:
How do I know if my encryption algorithm is strong enough?
then the probable short answer is:
- It is not strong.
- It is strong enough.
- It misses the point.
When professional cryptographers design an algorithm, they always assume that what they produced is weak. They will not trust it until it has been seriously looked at by their "fellow" cryptographers (who are actually their competitors, and a rather fierce bunch, though generally good humoured). It would not be wise, for a non cryptographer, to be less cautious than that.
Your algorithm is probably strong enough, where "enough" means "enough not to be the weakest point in your system". It takes really special effort to make a cryptographic algorithm which is so pathetically weak that attackers find it worthwhile to break it upfront (an example is CSS used on DVD, but that's still quite rare).
Your algorithm probably misses the point because most of security is not about cryptography ; cryptographic algorithms fulfill an important role, but with a narrow scope. I spend my days explaining to people that the magic crypto dust they sprinkled all over their systems is not as magic as they assumed (e.g. no, encrypting a SQL database does not prevent an attacker from successfully altering its contents by modifying the files on the disk).
It is possible that your algorithm (about which you give no detail at all) is actually strong, and fulfills a point which is relevant to your situation. Possible, but, as experience shows, not probable.
OK - so first it sounds odd that you are encoding a "user_id" (which sounds to me like a username) which I would think of as a relatively public piece of information - and not a password or something similarly secret - but the question is really about encryption, so I digress...
"Strong enough" for any encryption algorithm is rated by how long will it take to decrypt the text without having the key (presuming that you've hidden away your secret key in a good way). No algorithm is "perfect" except the classic One Time Pad - which is a fine academic example, but not so usable in 99% of cases, as it requires the same size key space as the data encrypted, and so you will be constantly generating and storing new key - which raises its own security concerns.
So.. any realistic algorithm is considered "strong enough" if it will take longer to decrypt the material w/out the key than the information is worth. So - if the information is my lunch plans for tomorrow, it's likely that my encryption algorithm may only need to delay an attacker 24 hours by which time, the event will be over, and it wouldn't matter cause you can't find me there anymore... but it may matter for years, if my lunch was some historic event or something.
So the factors of encryption cracking calculation include: - what are the weaknesses of the algorithm - some algorithms can have weak key sets that are easier to decrypt, others can get proved to add little value (some forms of DES)
what is the size of the key space - if all keys are equally secure, then the obvious way to crack the algorithm is to try every possible key of the given size - how many keys is a factor of storage size and the nature of how keys are chosen (for example, prime numbers are used in asymmetric encryption)
how hard is testing a decryption - how long will it take to try a test with a given key choice?
So... in a simple algorithm, time to crack can be:
# of keys in key space X time to test a key
That is usually factored over how many resources can you reasonably expect a hacker to have? A small organization may have 10-50 machines. A nation state may have millions. What is the nature of the threat - how much computational power can they reasonably have? You don't necessarily assume it's limited by their purchasing power at Best Buy - if they are technically sophisticated, they have a massively parallel botnet of malicious software on innocent user machines doing their computation.