Hi, > Is it possible to run a couple of test vectors through Python/PHP?
I will run some further tests. > Also, the final hex conversion from the library is causing you grief. > Could you send the results to a file, and then look at the file in a > hex editor? I've never observed a problem with Crypto++'s hex > converters. In don't think that there is a problem with cryptos hex converters, too. I will send the output to a file and check the result again. > Does mcrypt default to AES in CFB mode? I don't believe it is a > problem since sizeof(plain text) < sizeof(Block Size), but perhaps > $mode = MCRYPT_MODE_CFB [1] is required. The function is mcrypt_cfb. CFB is the default mode. > BLOCKSIZE = KEYLENGTH = 16. I'm not sure about the significance of 24 > bytes (AES key sizes are 16 to 32 bytes). Already tested. It does not change the result. If I extend the keylength to 32, the result is different, but there is still the difference between the crypto++ result and the PHP/Python result. PHP gives original: hello encoded (hex): 435b1b907a ----------------- Crypto++ gives original: hello encoded (hex): 436b18a5db The first number is correct again. > I don't believe CFB mode uses padding. So this should not be required > for Crypto++. You are right. StreamTransformationFilter sets the enumeration BlockPaddingScheme by default to No_Padding. However I added it to do some testings with other modes and since then didnt removed it. ;-) Maybe there are some implementation differences between crypto++ and PHP/Python libraries? Best regards, Stefan (Stephen) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
