> stfEncryptor.Put(reinterpret_cast<const unsigned
> char*>(plaintext.c_str()), plaintext.length() + 1);
Do the scripts include the trailing '\0' of 'Hello'?
Jeff
> There is a discrepancy between the higher hex
> numbers of the Crypto++ result and the Python/PHP results.
> But the first Hex number is always correct.
Is it possible to run a couple of test vectors through Python/PHP?
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.
> If you have PHP (mcrypt library) installed you can maybe verify it.
Sorry - I'm not a *nix kind of guy. Perhaps someone else can verify your script.
Some other thoughts which I do not believe to be a problem:
> Testing the CFB Mode...
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.
> AES::Encryption aesEncryption(key, 24);
BLOCKSIZE = KEYLENGTH = 16. I'm not sure about the significance of 24
bytes (AES key sizes are 16 to 32 bytes).
> StreamTransformationFilter::NO_PADDING);
I don't believe CFB mode uses padding. So this should not be required
for Crypto++.
Jeff
On 2/5/08, Jeffrey Walton <jeffrey....@gmail.com> wrote:
> Hi Stef,
>
> > There is a discrepancy between the higher hex
> > numbers of the Crypto++ result and the Python/PHP results.
> > But the first Hex number is always correct.
> Is it possible to run a couple of test vectors through Python/PHP?
>
> 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.
>
> > If you have PHP (mcrypt library) installed you can maybe verify it.
> Sorry - I'm not a *nix kind of guy. Perhaps someone else can verify your script.
>
> Some other thoughts which I do not believe to be a problem:
>
> > Testing the CFB Mode...
> 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.
>
> > AES::Encryption aesEncryption(key, 24);
> BLOCKSIZE = KEYLENGTH = 16. I'm not sure about the significance of 24
> bytes (AES key sizes are 16 to 32 bytes).
>
> > StreamTransformationFilter::NO_PADDING);
> I don't believe CFB mode uses padding. So this should not be required
> for Crypto++.
>
> Jeff
>
> [1] http://us.php.net/mcrypt
>
> On 2/5/08, StefSchultz <stef.s...@yahoo.com> wrote:
> >
> 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 <stef.s...@yahoo.com> wrote:
>
From cryptographic point of view I _strongly_ advice runnign CFB only in
128-bit mode.
> Is there a possibility to run Crypto++ with 8-bit CFB mode?
As you mention in your other postings, you've figured out how to do that -
but I recommend rather changing PHP or whatever to 128-bit CFB (and yes, it
has something to do with the cipher block-size, which for AES is 128 bits).