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! :-)