>Turns out I was barking up the wrong tree. My FoxPro (Craig Boyd) and .NET (Bouncy Castle) Blowfish encryption routines are returning encrypted strings of different lengths, and I thought this was the cause. Encoding.GetBytes(string) is being used to convert the string to byte[], and it successfully converted /n to a single CHR(10) byte. I'm not sure why the different lengths. Encrypting a 16-byte string in FoxPro returns a 16-byte encrypted string, in .NET it returns 24 bytes. Probably just an implementation difference. In my case, I was able to workaround by reducing my string to 15 bytes which gets the same result from Fox and .NET. Thanks for the help.
OK, but the wiki
http://en.wikipedia.org/wiki/Blowfish_(cipher) tells me it is a block cipher.
Its block size is 64 bits or 8 bytes. Now, if the input size is a multiple of the block size, the size of the output depends on the padding mode
http://msdn.microsoft.com/en-us/library/system.security.cryptography.paddingmode.aspxPadding mode NONE never pads, BUT the input size must be a multiple of the block size
Other padding modes pad data so that the output is a multiple of the block size. When the input is a multiple of the block size, a FULL block is added.
Hence 16 >> 24
If foxpro's size of the string is 16 AND the size of the byte array after encoding.GetBytes() is 16, then
check Boyd's parameters for the padding mode. If the two padding modes are the same, there may be a bug in Boyd's program
>>A string is composed of characters, think of it as a character array. Internally a char is represented in Unicode (UTF-16) and occupies 2 bytes
>>
>>C# is not converting it to '\n', it just displays it as '\n'
>>
>>Also, bear in mind that in C#, a character is kept in UTF-16 format
http://en.wikipedia.org/wiki/UTF-16/UCS-2>>
>>If the chars are later stored to say a text file, they are converted to a sequence of bytes using an Encodig
http://msdn.microsoft.com/en-us/library/system.text.encoding.aspx>>
>>A char can occupy 1, 2, 3 or 4 bytes depending on (1) The encoding and (2) the char itself
>>
>>Encrypting and Decrypting are never done on chars, but always on bytes
>>
>>Consider using bytes if possible
>>
>>
>>
>>>Here's my scenario: I am storing a small number as a single character in a string. If that number happens to be 10, C# is converting it to "\n". I imagine I will run into the problem with other escape codes as well. I really need CHR(10) to be stored in the string, not "\n". I've tried Convert.ToChar(myint), (char)myint, and even went so far as to use VisualBasic.Strings.Chr(), but it always comes back as "\n" in the string. The string is later encrypted, and that's where it is really messing things up. Is there anyway to "escape the escape" and prevent this from happening?
>>>
>>>Thanks.
Gregory