Curiouser and curiouser. The prior tests were on Windows (VS2013) using
the static library. I tried testing it on Linux with AddressSanitizer
(Clang 3.4) but this doesn't report any leaks -- I even tried explicitly
leaking some memory with a stray malloc and it didn't report that, so it's
obviously not working. I'm not sure if something special is required to
make it do something.
Trying Valgrind, it reported no definite CryptoPP leaks, but there were
some singletons still allocated. I'm not sure if they match the ones found
on Windows (there seem to be more of them) but for now I'm assuming this
was a false positive.
But another weird behaviour surfaced when I was testing it on Linux.
Following the prior RSA decrypt I added a more complex transformation:
CBC_Mode<AES>::Decryption aes(key.data(), key.size(), iv.data());
RSASS<PKCS1v15, SHA256>::Verifier verifier(publicKey);
auto snf = new SignatureVerificationFilter(verifier, new StringSink(
plaintext),
SignatureVerificationFilter::PUT_MESSAGE | SignatureVerificationFilter::
SIGNATURE_AT_BEGIN);
StringSource source1(ciphertext, true, new StreamTransformationFilter(aes,
new StringSink(decrypted_data)));
StringSource source2(decrypted_data, true, new Gunzip(new StringSink(
uncompressed_data)));
StringSource source3(uncompressed_data, true, snf);
assert(snf->GetLastResult());
The above code runs and passes on both Windows and Linux, and I've verified
that the final plaintext is correct (which you would hope is the case when
the signature verifies). But keeping the preamble and replacing the
sources with this:
StringSource source(ciphertext, true, new StreamTransformationFilter(aes,
new Gunzip(snf)));
assert(snf->GetLastResult());
This runs and passes on Windows, but on Linux while it runs and appears to
generate the correct plaintext (I only verified the first hundred bytes, as
the test data was fairly large), the assertion fails. Isn't this how
you're supposed to chain filters? Why does it work on Windows but not
Linux?
Possibly of note is that merging source1 and source2 seems to be ok, but
merging source2 and source3 is not. Perhaps Gunzip and
SignatureVerificationFilter don't like each other (but only on Linux)?
On Tuesday, June 28, 2016 at 10:08:05 AM UTC+12, Gavin Lambert wrote:
>
> The leaks still appear to be present with current master code.
>
> On Monday, June 27, 2016 at 8:29:27 PM UTC+12, Gavin Lambert wrote:
>>
>> Hi, I'm using Crypto++ for the first time, to do some decryption and
>> verification. I've downloaded the 5.6.3 release zip.
>>
>> I've written some test code using the RSA example on the wiki as a basis,
>> but I'm getting memory leaks reported; unfortunately the leak detector I'm
>> using only reports the location of the "new", not a full call stack, and
>> due to Crypto++'s code structure this doesn't help me find the root cause.
>>
>> The code is fairly straightfoward:
>>
>> using namespace CryptoPP;
>>
>> RSA::PrivateKey privateKey;
>> privateKey.Load(...); // verified this doesn't leak; it's a 3072-bit key
>> std::string ciphertext(raw_ciphertext, sizeof(raw_ciphertext)); // 384
>> bytes
>>
>> RSAES_OAEP_SHA_Decryptor decryptor(privateKey);
>> AutoSeededRandomPool rng;
>> SecByteBlock decrypted(decryptor.MaxPlaintextLength(ciphertext.size());
>> auto result = decryptor.Decrypt(rng, (const uint8_t*)ciphertext.data(),
>> ciphertext.size(), decrypted);
>> assert(result.isValidCoding);
>> decrypted.resize(result.messageLength);
>> assert(0x20 == result.messageLength);
>>
>> The resulting decrypted data is correct. but after the function
>> containing the above exits (so all objects should have been destroyed) I
>> get the following leaks reported:
>>
>> Memory leak(s) found.
>> Alloc num (658157) Leak size: 4 Allocated at: misc.h and line: 202. Type:
>> "new"
>> Memory: <01A698E8> Content:
>> 0000: 28 63 a6 01 |(c..|
>> Alloc num (658163) Leak size: 4 Allocated at: misc.h and line: 202. Type:
>> "new"
>> Memory: <01A695D0> Content:
>> 0000: 50 3c 3c 01 |P<<.|
>> Alloc num (658165) Leak size: 20 Allocated at: integer.cpp and line:
>> 2922. Type: "new"
>> Memory: <01A43798> Content:
>> 0000: 48 0d 43 01 cd cd cd cd 02 00 00 00 d8 c2 9f 01
>> |H.C.............|
>> 0010: 00 00 00 00 |....|
>>
>> FWIW, the first two leaks are in NewObject and the last one is in
>> NewInteger (as I said, doesn't seem particularly helpful on its own).
>>
>> Is this a known issue? Is there something else I need to call to clean
>> up the memory?
>>
>
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
