Thanks for the report. I've checked in fixes for these 3 problems. Let me know if you find anything else.
On Sun, Mar 07, 2004 at 11:30:59PM -0700, Ed Addario wrote: > Hello, > > First, a huge thanks to Wei Dai for such an extraordinary library. By using > it, I've not only increased my knowledge in cryptography but also learned a > few coding tricks. > > Next, let's do the numbers: > > Crypto++ 5.1 and a full CVS checkout as of 1/12/04, WinXP SP1 , MS C++ > Compiler v.13.10.3077 (.NET 2003) and Intel C++ Compiler v. 8.0.040 > > Lastly, I've a couple of observations: > > a. Some hash algorithms like HAVAL and PanamaHash can't be used to > instantiate HMAC objects: > > HashTransformation* hash = new HMAC<HAVAL5>(input, length); or, > HashTransformation* hash = new HMAC<PanamaHash<LittleEndian> >(input, > length); > > will produce a "StaticAlgorithmName : is not a member of CryptoPP::(the > respective class)" compile error. I don't consider this a bug since it's > documented that not all classes implement the StaticAlgorithmName method yet > and the solution is trivial, but I just wanted to point it out. > > b. In the latest Crypto++ track (in CVS), version 1.5 of algparam.h > introduced additional support for encoding parameters and "MakeParameters" > was changed to include a third parameter "throwIfNotUsed = true". This > causes a change in the behavior of classes that take parameters that are not > used. For example: > > CBC_Mode<AES >::Encryption cfbEncryption(key, keylength, iv); (there's an > implicit feedbackSize=0) > > will now throw a "feedbackSize not used" exception. As I see it, there are > two possible solutions/workarounds: > > 1) Change the CipherModeFinalTemplate_CipherHolder (and others) method from: > > CipherModeFinalTemplate_CipherHolder(const byte *key, unsigned int length, > const byte *iv, int feedbackSize=0) to, > > CipherModeFinalTemplate_CipherHolder(const byte *key, unsigned int length, > const byte *iv) > CipherModeFinalTemplate_CipherHolder(const byte *key, unsigned int length, > const byte *iv, int feedbackSize) or, > > 2) make throwIfNotUsed = false > > After some investigations, I think the latter is the preferred. Comments? > > c. I believe SHACAL-2 is Variable Key Length with a default/minimum keysize > of 128 bits and a maximum of 512. But in Crypto++'s implementation if the > key is not a 32 bit multiple, Encryption or Decryption will violate > assert(inlen <= outlen*U) in method GetUserKey (misc.h). > > Am I making the wrong assumption? Should "struct SHACAL2_Info : public > FixedBlockSize<32>, public VariableKeyLength<16, 16, 64>" be implemented as > "struct SHACAL2_Info : public FixedBlockSize<32>, public > VariableKeyLength<16, 16, 64, 4>"? > > Thanks for any comments/corrections > > - Ed Addario > > _________________________________________________________________ > Fast. Reliable. Get MSN 9 Dial-up - 3 months for the price of 1! > (Limited-time Offer) http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
