After HMAC is keyed (which you did in the constructor and can also do
via SetKey() ) it behaves like a normal hash function, so Update() and
Final() or CalculateDigest() are your methods of choice.

So it would be something like:

HMAC<SHA256> hmac(key,keySize); // replace with your parameters
hmac.CalculateDigest(target,input,inputSize); // replace with your parameters

If you want to stay with the old style.
For the fancy Filter-Source based style, look in the following wiki page
and replace SHA256 with HMAC<SHA256> and key it in the constructor.
https://cryptopp.com/wiki/HashFilter

BR

JPM

Am 21.09.2016 um 15:46 schrieb edwin schriek:
> Thanks for your answer,
>
> Your statement about security makes sense, the thing is that this code
> was written 20 years ago by some developer and I do not know his
> intention/philosophy behind this encryption/decryption mechanism.
> With that being said, fixing the current construction, which is
> considered dangerous according to your story, is sufficient. At least
> for now, since my only 'task' is to have our project running on
> various platforms (Android/iOS).
>
> One final request; could you help me write the code for the HMAC? I
> barely know the cryptopp api and I know even less about cryptography.
> I figured I need something like the following,
>
> CryptoPP::HMAC<CryptoPP::SHA256> hmac(pKey, dwKeySize);
> CryptoPP::StringSource ss(m_bufSeed, true,
>   new CryptoPP::HashFilter(hmac,
>   new CryptoPP::StringSink(hmac)
>       )
> );
>
>
>
> Op woensdag 21 september 2016 15:00:04 UTC+2 schreef jean-pierre.muench:
>
>     The issue you seem to have is that the RNG is, well, actually
>     producing random results.
>
>     If you want deterministic behavior, you should avoid RNGs if possible.
>
>     To clarify, I'm trying to draw a picture of the old IV generation:
>
>     Key -> SHA256 -> RandomPool -> SHA256 -> XOR "compression" -> IV
>       |                             |
>       +---------------------+
>
>     From what I can see, your implementation always tries to produce a
>     static IV, which is only dependent on the key. This is only fine
>     if you never re-use the key, e.g. you never instantiate (and use)
>     a second instance with the same key (for encryption). Otherwise
>     this is an IV re-use which is horribly broken and allows for
>     really easy attacks.
>
>     Another issue that I see in this code is the complete absence of
>     authentication. If an attacker manipulates the cipher text you've
>     no chance of (cryptographically reliably) detecting it. The fix
>     would be to use a mode like GCM or EAX.
>
>     To fix your current construction (and get the same dangerous
>     behavior back), you can replace RandomPool with HMAC<SHA256> and
>     feed the key in as the key and the hashed key as the message.
>
>     To actually fix the problems, you should use
>
>      1. Authenticated encryption
>      2. Explicitly or implicitly set a new IV / nonce for each message
>         (either by using a deterministic counter or by generating the
>         IV / nonce at random)
>
>     Here are the related wiki pages for EAX and GCM
>
>       * https://cryptopp.com/wiki/EAX_Mode
>         <https://cryptopp.com/wiki/EAX_Mode>
>       * https://cryptopp.com/wiki/GCM_Mode
>         <https://cryptopp.com/wiki/GCM_Mode>
>
>     BR
>
>     JPM
>
>
>     Am 21.09.2016 um 11:06 schrieb edwin schriek:
>>     Hi,
>>
>>     We are updating a project which uses the ancient cryptopp 4.2, to
>>     the latest version in order to have better cross platform support
>>     (4.2 suffers from undefined behaviour under platforms like
>>     Android/iOS).
>>     In this project, we use AES to decrypt/encrypt some data, nothing
>>     to fancy.
>>
>>     Now, the problem when moving to the newer version lies in
>>     generation the IV.
>>     The code used to generate our IV is as follows:
>>
>>     |
>>     BOOL CCryptorAES101::Init(BYTE*pKey,DWORD dwKeySize)
>>     {
>>      ASSERT(pKey);
>>
>>
>>      m_bInit =true;
>>
>>
>>      try
>>      {
>>      CryptoPP::SHA256         hash;
>>      CryptoPP::RandomPool    rng;
>>      CryptoPP::MySecByteBlockbufSeedIV(IV_SEED_SIZE);
>>
>>
>>      m_bufSeed.Resize(hash.DigestSize());
>>      m_bufIV  .Resize(IV_SIZE);
>>
>>
>>      hash.CalculateDigest(m_bufSeed,pKey,dwKeySize);
>>      rng.Put(pKey,dwKeySize);
>>      rng.GenerateBlock(bufSeedIV,bufSeedIV.Size());
>>
>>
>>      CryptoPP::MySecByteBlockbufHash(hash.DigestSize());
>>
>>
>>      hash.CalculateDigest(bufHash,bufSeedIV.Begin(),bufSeedIV.Size());
>>
>>
>>      ASSERT(2*m_bufIV.Size()==bufHash.Size());
>>
>>
>>      for(inti =0;i <m_bufIV.Size();i++)
>>      m_bufIV[i]=bufHash[i]^bufHash[i +16];
>>
>>
>>      }
>>      catch(CryptoPP::Exceptionconst&e)
>>      {
>>      UNUSED_ALWAYS(e);
>>
>>
>>      m_bInit =false;
>>      
>>      returnfalse;
>>      }
>>
>>
>>      returntrue;
>>     }
>>     |
>>
>>
>>     The following code does the actual decryption:
>>
>>     |
>>     BOOL CCryptorAES101::Decrypt(BYTE*pData,DWORD dwSize)
>>     {
>>      if(!m_bInit)
>>      returnFALSE;
>>
>>
>>      try
>>      {
>>     #if CRYPTO_VER == 42
>>      CryptoPP::AESEncryptionaes(m_bufSeed,m_bufSeed.Size());
>>      CryptoPP::CFBDecryptiondecryptor(aes,m_bufIV);
>>     #else
>>      CryptoPP::AES::Encryption                   
>>     aes(m_bufSeed,m_bufSeed.size());
>>      CryptoPP::CFB_Mode_ExternalCipher::Decryptiondecryptor(aes,m_bufIV);
>>     #endif
>>      decryptor.ProcessString(pData,dwSize);
>>      }
>>      catch(CryptoPP::Exceptionconst&e)
>>      {
>>      UNUSED_ALWAYS(e);
>>
>>
>>      returnFALSE;
>>      }
>>
>>
>>      returnTRUE;
>>     }
>>
>>     |
>>
>>
>>     Under cryptopp 4.2, bufSeedIV is always the same, resulting in a
>>     bufHash and m_bufIV which are always the same. 
>>     Under cryptopp 5.6.4 however, bufSeedIV is always different, this
>>     is our problem.
>>
>>     As far as I can figure, the RandomPool implementation changed
>>     over time, but I could be wrong.
>>
>>     Any guidance would be appreciated!
>>
>>     Kind regards,
>>
>>     Edwin
>>     -- 
>>     -- 
>>     You received this message because you are subscribed to the
>>     "Crypto++ Users" Google Group.
>>     To unsubscribe, send an email to
>>     cryptopp-user...@googlegroups.com <javascript:>.
>>     More information about Crypto++ and this group is available at
>>     http://www.cryptopp.com.
>>     ---
>>     You received this message because you are subscribed to the
>>     Google Groups "Crypto++ Users" group.
>>     To unsubscribe from this group and stop receiving emails from it,
>>     send an email to cryptopp-user...@googlegroups.com <javascript:>.
>>     For more options, visit https://groups.google.com/d/optout
>>     <https://groups.google.com/d/optout>.
>
> -- 
> -- 
> You received this message because you are subscribed to the "Crypto++
> Users" Google Group.
> To unsubscribe, send an email to
> cryptopp-users-unsubscr...@googlegroups.com.
> More information about Crypto++ and this group is available at
> http://www.cryptopp.com.
> ---
> You received this message because you are subscribed to the Google
> Groups "Crypto++ Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cryptopp-users+unsubscr...@googlegroups.com
> <mailto:cryptopp-users+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to