>>Craig,
>>
>>Now that you're back amongst the living ...
>>
>>Would you mind telling what IV (initialization vector) you are using ?
>>
>>Any possibility to add a parameter to encrypt/decrypt that accepts an IV for CBC mode
>>
>>Thanks,
>
>IV currently left as default (in the case of AES that's 32 byte array of nulls). As to the possibility of adding a parameter to specify the IV, yes. That was always the plan for modes CBC and CFB. Ideally I would allow devs to set IV and size then it could match .NET's (Rijndael/RijndaelManaged CreateDecryptor() for instance where the IV is 16 bytes i believe). I would also allow key length, block size, and block padding to be specified where applicable/allowed to vary. Also, could do something similar to .NET's PasswordDeriveBytes where a salt and key are fed to a hash to create an internal key actually used to encrypt the data. I'd like to provide as much compatibility with .NET and other platforms' implementations as possible so Visual FoxPro apps can freely produce/consume encrypted data from other sources. Not there yet, but someday.


Craig,

The length of the IV is equal to the length of the blocksize. For AES, that's always 16 bytes
Rijndael lets you set the blocksize (so setting it to 128 behaves like AES)

Some observations

(1) I believe you are padding with 0x00
(2) I can get aes128, 192 and 256 to work with the windows crypt api but only in the following configuration: ECB and padding mode PKCS7
CBC, I cannot get it to work. The api decrypts what it has encrypted, but if I pass the encrypted data to Aes in .net, I do not get the original data back

(3) Some test vectors are here http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

(4) I have run vfpencryption.fll on those testvectors
All tests below:
- IV byte[16] (or byte[32] for Rijndael with blocksize of 256) initalized to 0x00
- ECB
- paddingMode = zeros

all inputs : 4EC137A426DABF8AA0BEB8BC0C2B89D6
since there is zero padding I only look at the first 16 bytes of the output I get

(a) aes128
key :	95A8EE8E89979B9EFDCBC6EB9797528D
expect:	D9B65D1232BA0199CDBD487B2A1FD646
get : 	F9ED5FA48D9222C81F3F3A378B39C7B1C394169AEB1F290AD2CDD43A18378CAC


(b) aes 192
key :	95A8EE8E89979B9EFDCBC6EB9797528D432DC26061553818
expect:	B18BB3E7E10732BE1358443A504DBB49
get : 	80ACFF918CECDC3AD5375437891E283DB1886EF5B74F91CE6FB453D8E553F492

(c) aes 256
key :	95A8EE8E89979B9EFDCBC6EB9797528D432DC26061553818EA635EC5D5A7727E
expect:	2F9CFDDBFFCDE6B9F37EF8E40D512CF4
get : 	42C0068416C9FF4B3DD79EF2573C2CB7569D39C75B592C72945E6E035AFB71F6

I get the good results both with AES.net and Rijndael (Rijndael blocksize set to 128 bits)

I have done the three tests with Rijndael set to 256 bits blocksize - and - they are equal to your output
So, you are returning Rijndael with blocksize of 256 bits instead of AES with a blocksize of 128 bits