How secure is this algorithm?

Question

I made a simple encryption program. It works like this: the ascii value of every character in string A is added to the ascii value of the corresponding character in string B. If the value is greater than 255 or less than 0, it is wrapped around; if string B is shorter than string A, it is repeated.

For example, using this algorithm on the following strings:

"The quick brown fox jumps over the lazy dog" (string A)

and "Jackdaws love my big sphinx of quartz" (string B)

will output:

"žÉÈ‹ÕÖàÖ‹ŒÑèÔ—Û™†ÑᇊèÝØÜŽç–ÔØ@åÝÆ’àÛ...

Decryption works in reverse - the ascii value of each character in string B is subtracted from the ascii value of each character in the encrypted string.

How easy/hard would it be to decrypt the output string if string B is unknown? Also, how secure (and practical) is the algorithm in general?

Answer 1

First, consider using XOR instead of addition.  In C++:

unsigned char b1, b2;

b1 ^= b2;  // b1 is now itself xor b2

b1 ^= b2;  // the original value of b1 is restored

               // by xor'ing itself to b2 again

An XOR can always be undone, and there is never any chance of overflow.  XOR also infantessimally faster than ADD, but with modern hardware, it soooo doesn't matter any more, unless perhaps you're writing server-side code that requires maximum possible scalability.  (I only mention it as an obtuse reference to my decades in the business.)  :-)

And lastly, I really hate to tear you down -- as has already been mentioned, most people (myself included) would look at your cipher and figure, hmm, guess he didn't want me to know the value.  :-)  But you did ask, so... string B can be easily derived by anyone able to specify the value of string A, by passing a string of blank spaces, or an array of zeros.  Once your key and it's period are known, your ciphers become an open book.

I once implemented a password encryption scheme in T-SQL, it used facets of the value to be encrypted to vary the way the key was applied to it -- particularly multiple contiguous characters -- attempting to avoid an easily detectable pattern.  

One weakness: it does not guarantee bi-directional perfection, it is not always possible to obtain the original value from the encrypted value.  But this was workable, it's purpose was to make sure a user-entered credential matched the password on file, so all it needed was one-way consistency; decrypting the stored password is pointless, given that it matches the encrypted credential.

The code continues to serve its purpose as we speak, but CAPICOM is so easy to use, I'll take MD5 or AES over my home-grown stuff any day.

Now if only .NET's crypto interface was even 1/10th as easy to use as CAPICOM, I'd have one less interop to worry about.  :-)

Good Luck!  :-)

Answer 2

read the first part of your article...dont let this get you down it will fool alot how ever all the simple ones are known keep working there always room for one more