I forgot - I'm using CryptoPP 5.6.1
On Feb 21, 4:43 pm, User56784 <r.ja...@comcast.net> wrote:
> Hi,
>
> I’m hitting an assert at line 197 in secblock.h when using AES-CBC
> encryption with 256 bit key. It started with occasional failure when
> generating random keys and I could not find out what’s causing the
> problem, because I needed many attempts to get repro. Later on when I
> had a few keys stored in a file, I was able to reproduce this issue
> 100%.
>
> Here is my code
>
> void CryptoAES::Encrypt(byte * input, byte * output, in length, byte
> key[], byte iv[])
> {
> CBC_Mode<AES>::Encryption cfbEncryption(key, KeyLength,
> iv); // ASSERT VIOLATION
> cfbEncryption.ProcessData(output, input, length);
>
> }
>
> ASSERT at line 197 in secblock.h
>
> template <class T, size_t S, class A = NullAllocator<T>, bool
> T_Align16 = false>
> class FixedSizeAllocatorWithCleanup : public AllocatorBase<T>
> {
> ...
> void deallocate(void *p, size_type n)
> {
> if (p == GetAlignedArray())
> {
> assert(n <= S);
> ===> assert(m_allocated); // ASSERT VIOLATION
> m_allocated = false;
> SecureWipeArray((pointer)p, n);
> }
> else
> m_fallbackAllocator.deallocate(p, n);
> }
> ...
>
> }
>
> I reuse key and iv arrays and just overwrite bytes in these 2 arrays
> with a new key and initialization vector for each new encryption/
> decryption, so I thought that this can cause a problem when
> cfbEncryption gets out of scope, however deleting key and iv and
> creating a new instance (key = new byte[KeyLength], iv = new
> byte[IVLength]) did not solve the problem. The assert violation seems
> to be caused by certain combinations of key and initialization vector.
> What helped me solve the problem was rewriting the code mentioned
> above as follows:
>
> void CryptoAES::Encrypt(byte * input, byte * output, in length, byte
> key[], byte iv[])
> {
> CBC_Mode<AES>::Encryption * cfbEncryption = new
> CBC_Mode<AES>::Encryption(key, KeyLength, iv);
> cfbEncryption->ProcessData(output, input, length);
> delete cfbEncryption;
>
> }
>
> I could use this new code which fixes the problem, but I don’t want to
> ignore that assert. Rewriting the code might just move the problem
> elsewhere and create potential heap corruption. There has to be a
> reason for this assert violation.
> Does anybody know what the problem is? Why certain combinations of key
> and iv causes the problem?
>
> Thanks.
--
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.
