Re: AES-256 CBC - hitting assert at line 197 in secblock.h
I have tried with CRYPTOPP_BOOL_ALIGN16_ENABLED 0, but encryption/ decryption stopped working completely. Perhaps this flag can be used only on big-endians to make bytes ordered correctly. But thanks for info, it definitely must be some issue with allocator/ deallocator, because in deallocator function it things that m_allocated is false. This leads me to another possible cause and that is handling of input data. I always cleanup input arrays and have my own ShredByteArray function, but it looks like secblock.h has already something similar in place - SecureWipeArray. In my code I overwrite existing arrays and reuse them for the next round of encryption/decryption and only shred data and 'delete []' when I'm done. It is possible that I'm just using it wrong and I should pass input arrays and forget it and let deallocator do it's job. However I haven't found in the documentation what the correct usage is. Examples usually don't include clean up steps. I worry about memory leaks, so I do the clean up myself. It would be nice if docs said explicitly call delete [] Key, delete [] IV and delete [] inputArray after calling Encrypt/Decrypt or call delete [] inputArray, but DO NOT clean up key and iv, it's being taken care of in deallocator function. -- 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.
Re: AES-256 CBC - hitting assert at line 197 in secblock.h
On Feb 21, 7: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_ModeAES::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 = NullAllocatorT, bool
T_Align16 = false
class FixedSizeAllocatorWithCleanup : public AllocatorBaseT
{
...
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_ModeAES::Encryption * cfbEncryption = new
CBC_ModeAES::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?
I experienced a similar problem on iPhone when using a PRNG
(AutoSeededRandomPool). I seem to recall that first time through,
everything was OK. But the second time the allocator was used, there
was a problem.
You might try the following. Place it in config.h, after Crypto++ auto-
configures the value for CRYPTOPP_BOOL_ALIGN16_ENABLED.
# undef CRYPTOPP_BOOL_ALIGN16_ENABLED
# define CRYPTOPP_BOOL_ALIGN16_ENABLED 0
Jeff
--
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.
AES-256 CBC - hitting assert at line 197 in secblock.h
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_ModeAES::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 = NullAllocatorT, bool
T_Align16 = false
class FixedSizeAllocatorWithCleanup : public AllocatorBaseT
{
...
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_ModeAES::Encryption * cfbEncryption = new
CBC_ModeAES::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.
Re: AES-256 CBC - hitting assert at line 197 in secblock.h
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_ModeAES::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 = NullAllocatorT, bool
T_Align16 = false
class FixedSizeAllocatorWithCleanup : public AllocatorBaseT
{
...
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_ModeAES::Encryption * cfbEncryption = new
CBC_ModeAES::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.
