AFAIK most of the stuff you do to
fight off crackers is about hidden tests and traps for obvious reasons?
For software-protection and something like this its the case. If a hacker knows your protection-scheme he can break it, because software-protection has to use the same algorithm on each startup. The only chance is to confuse the hacker by adding multiple checks and other obfusing things for validating the copy of the program. But when the hacker knows all of these traps he can easily break them.
Same with at any time when you need to use a fixed key, because you don't want do bother the user with a password. As soon as an attacker knows how it works, he can break it.
For en/decryption used for communication it is a totally different application for encryption schemes. The persons that want to talk to each other do have a common secret, the key. And all other things should be assumed to be public domain, otherwise it is commonly seen as unsecure. Even easiest encryption schemes such as substitution cipher do achieve this goal (and your procedures using a password for the random seed, too).
But the disadvantage then is, that the user has to know and type in a kind of password for the key.
So finally:
Using these procedures for obfuscating hackers by e.g. storing some strings encoded in a file, they are ok as they are. But for a
secure encrypted communication they are not applicable.
