PureBasic Forums - English

@citystate, you're right. See Ricardos first post in this thread, where he uses one procedure. I
just divided them up for clarity, but they could be the same procedure.

froggerprogger wrote:

So your security bases on the fact that the attacker doesn't know how your encryption scheme
works, what is very bad

I agree with most of what you say, but not necessarily this quote. AFAIK most of the stuff you do to
fight off crackers is about hidden tests and traps for obvious reasons?

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.

Thanks for the info!