>>>>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.aspx
>>>
>>>Padding 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
>>>
>>>
>>>
>>>
>>

>>

>>Joel,
>>
>>As a follow up - I am (quite) reluctant to use Boyd's FLLs
>>
>>Re: Zipping Thread #1541146 Message #1541195
>>Re: VfpEncryption.fll - aes encrypt/decrypt Thread #1413527 Message #1414160
>>
>>A couple of alternatives
>>
>>(1) If you can use AesManaged ( http://msdn.microsoft.com/en-us/library/system.security.cryptography.aesmanaged(v=VS.95).aspx ) in .Net
>>I can give the code in foxpro which uses win api - faster for longer blocks, slower for shorter blocks due to the frequency of the api calls
>>
>>CypherMode: ECB or CBC
>>PaddingMode : PKCS7
>>Key: 128, 192 or 256 bits
>>Block Size: AES always 128 bits
>>With IV (Initialisation Vector)
>>
>>(2) If you can use RijndaelManaged ( http://msdn.microsoft.com/en-us/library/system.security.cryptography.rijndaelmanaged.aspx )
>>
>>I can give the code in pure foxpro - quite optimised
>>
>>CypherMode: ECB or CBC
>>PaddingMode : NONE, PKCS7, ANSIX923, ISO10126
>>Key: 128, 192 or 256 bits
>>Block Size: 128, 192 or 256 bits
>>With IV (Initialisation Vector)
>
>Yes, I think you are right, it is about padding, because I could still successfully decrypt the 24-byte string in FoxPro. Rijndael/AES was my first choice, but it returned 32 bytes in my tests. I'm generating license activation keys that may be read over the phone, so I want to keep them as short as possible for our support people. Blowfish returned 16 bytes, so I chose it. Part of my keys were random filler, so I was able to reduce that by one character and avoid the problem. I'm good now, but I'll take note of these suggestions if I run into problems in the future. I appreciate it.


The blocksize of AES is 128 bits or 16 bytes. I'm pretty sure that if you're data to encrypt is 15 bytes, only one padding byte will be added resulting in 16 bytes total

If you take Rijndael with blocksize 128 bits, padding mode NONE and your data is 16 bytes, no padding will be added, resulting in 16 bytes in total

Good luck,