Hi All,
Should anyone be following the play by play. I ended up punting on the
0 size MAC, settling for a 4 byte MAC. I would have liked to reduce to
2 bytes by using a word16 (or even 1 byte using a word8), but the base
classes are built upon a word32.
Operating on a 33 bit curve, I went from a 56 byte Ciphertext object
(C,V,T) to a 31 byte object. A true NULL HMAC implementation achieved
a 28 byte Ciphertext object (C,V,T) with the same curve, but would not
Decrypt with my modifications.
Jeff
// Crypto++ Includes
// Expedient Implementation of a NULL Hash
#include "cryptlib.h"
#include "iterhash.h"
// TRUEHash
// A hash that always returns 0x01
// This is a Visual C++ workaround (possibly others)
// due to not being being able to create a NULL HMAC class
// The NULL HMAC cannot compile due to a digest size of 0
// because of array sizing of 0 (major problems in SecByteBlock())
class TRUEHash : public
CryptoPP::IteratedHashWithStaticTransform<CryptoPP::word32,
CryptoPP::BigEndian, 32, 4, TRUEHash>
{
public:
static void InitState(HashWordType *state)
{ state[0] = 0x01; return; }
static void Transform(CryptoPP::word32 *digest, const
CryptoPP::word32 *data) { return; }
static const char *StaticAlgorithmName() {return "TRUE HASH";}
};
// Crypto++ Includes
// Template Specialization modification of
// struct ECIES in ecccrypto.h
#include "pubkey.h"
#include "dh.h"
#include "sha.h"
#include "eccrypto.h"
#include "ecp.h"
template <class EC, class COFACTOR_OPTION =
CryptoPP::NoCofactorMultiplication, bool DHAES_MODE = false>
struct ECIESNullT
: public CryptoPP::DL_ES<
CryptoPP::DL_Keys_EC<EC>,
CryptoPP::DL_KeyAgreementAlgorithm_DH<typename EC::Point,
COFACTOR_OPTION>,
CryptoPP::DL_KeyDerivationAlgorithm_P1363<typename EC::Point,
DHAES_MODE, CryptoPP::P1363_KDF2<CryptoPP::SHA1> >,
CryptoPP::DL_EncryptionAlgorithm_Xor<CryptoPP::HMAC<TRUEHash>,
DHAES_MODE>,
CryptoPP::ECIES<EC> >
{
static std::string StaticAlgorithmName() {return "ECIES with NULL T";}
};
