The change I proposed tried to maintain the same flow as closely as
possible, making HMAC the obvious choice here. If you wanted to exact
same results as from 4.2, you'll either have to inspect the 4.2 code and
try and reproduce the same results (shouldn't be too hard) or you just
copy and paste the implementation from 4.2 into your new project, rename
it and be done with it.
BR
JPM
Am 21.09.2016 um 16:47 schrieb edwin schriek:
> I came up with the following based on your remarks, instantiated the
> HMAC with the key and fed the hashest key as the message.
> However, output does not coincide with that of the old code.
>
> |
> CryptoPP::SHA256 hash;
>
> m_bufSeed.Resize(hash.DigestSize());
> m_bufIV.Resize(IV_SIZE);//16
>
> hash.CalculateDigest(m_bufSeed,pKey,dwKeySize);
>
> CryptoPP::HMAC<CryptoPP::SHA256>hmac(pKey,dwKeySize);
> CryptoPP::MySecByteBlockbufHmac(hmac.DigestSize());
>
> hmac.CalculateDigest(bufHmac,m_bufSeed,m_bufSeed.Size());
>
> for(inti =0;i <m_bufIV.Size();i++){
> m_bufIV[i]=bufHmac[i]^bufHmac[i +16];
>
>
> TRACE("%d ",m_bufIV[i]);
> }
> |
>
>
> Op woensdag 21 september 2016 16:05:46 UTC+2 schreef jean-pierre.muench:
>
> 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
> <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. 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. 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-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.
