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