Hi Stefan, > Maybe there are some implementation differences between > crypto++ and PHP/Python libraries? Perhaps, but there should not be. The Crypto++ library is NIST certified. This means (among other things) NIST tested the Crypto++ implementations (the binary was provide by Wei to NIST). If there is a difference, I would expect it to lie outside of Crypto++.
The best I can recommend to verify the integrity of Crypto++ on you (Linux?) installation is to run the validation test. I believe it is ./cryptest.exe -v. If you tank on validation, all bets are off. Perhaps the WINE emulator is causing you grief. FIPS 197, Appendix C includes AES test vectors (http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf). Have you had an opportunity to run them through mcrypt? Finally, FIPS 800-38A (http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf) specifies five modes of operation (CFB is one of them). Test vectors are included in Appendix F. CFB mode is Appendix F, Section 3. Jeff On 2/5/08, StefSchultz <[EMAIL PROTECTED]> wrote: > > 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. -~----------~----~----~----~------~----~------~--~---
