[cryptopp-users] Re: Fixing confirmed memory leaks in CryptoPP?

[The P.E.N.]

Dear Jeffrey,

OK then, I'll give it another shot.  What I need to do is avoid the dll 
altogether, include just the necessary headers, expressly build in any 
actually required functions, and especially swear off any pipelining so i 
can isolate problem points.

Thank you again for your gracious help.

Peace,

Pen





On Friday, September 24, 2021 at 9:22:31 AM UTC-7 Jeffrey Walton wrote:

> On Friday, September 24, 2021 at 12:16:22 PM UTC-4 activis...@gmail.com 
> wrote:
>
>> I have already foregone the use of dynamic thread creation for similar 
>> reasons.  That is, after program initialization no new threads are ever 
>> created.  All I need now are the bare bones functions standing alone to 
>> sign, and then verify a message using ECDSA SHA 256 with secp256k1 keys.
>>
>
> https://www.cryptopp.com/wiki/Elliptic_Curve_Digital_Signature_Algorithm 
> and https://www.cryptopp.com/wiki/Wrapper_DLL
>
> This is just pure math isn't it?  And if verifiers, string sinks, or 
>> whatever have to be allocated as "new," why cannot they be cleanly freed 
>> after use in scope? 
>>
>
> https://www.cryptopp.com/wiki/Pipelining#Ownership
>
> Jeff
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/4e8a7566-65d5-4a60-9e2d-fcf152e992c7n%40googlegroups.com.

[cryptopp-users] Re: Fixing confirmed memory leaks in CryptoPP?

[Jeffrey Walton]

On Friday, September 24, 2021 at 12:16:22 PM UTC-4 activis...@gmail.com 
wrote:

> I have already foregone the use of dynamic thread creation for similar 
> reasons.  That is, after program initialization no new threads are ever 
> created.  All I need now are the bare bones functions standing alone to 
> sign, and then verify a message using ECDSA SHA 256 with secp256k1 keys.
>

https://www.cryptopp.com/wiki/Elliptic_Curve_Digital_Signature_Algorithm 
and https://www.cryptopp.com/wiki/Wrapper_DLL

This is just pure math isn't it?  And if verifiers, string sinks, or 
> whatever have to be allocated as "new," why cannot they be cleanly freed 
> after use in scope? 
>

https://www.cryptopp.com/wiki/Pipelining#Ownership

Jeff

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/dd806d01-67a9-417c-9236-f6af44ad47e0n%40googlegroups.com.

[cryptopp-users] Re: Fixing confirmed memory leaks in CryptoPP?

[The P.E.N.]

Dear Jeffrey,

Thank you for your prompt and kind attention.

I have already foregone the use of dynamic thread creation for similar 
reasons.  That is, after program initialization no new threads are ever 
created.  All I need now are the bare bones functions standing alone to 
sign, and then verify a message using ECDSA SHA 256 with secp256k1 keys.

Is there any way to do this with CryptoPP?

This is just pure math isn't it?  And if verifiers, string sinks, or 
whatever have to be allocated as "new," why cannot they be cleanly freed 
after use in scope? 
 
Peace,

Pen


  

On Friday, September 24, 2021 at 8:44:24 AM UTC-7 Jeffrey Walton wrote:

> On Thursday, September 23, 2021 at 4:01:30 PM UTC-4 activis...@gmail.com 
> wrote:
>
>> Hello fellow coders,
>>
>> I am working on what is intended as a long running crypto comm 
>> application written in c++.  As a consequence there can be NO memory leaks.
>>
>> I've got the CryptoPP library working just fine to sign and verify 
>> signatures but there are memory leaks being reported by Memory Validator 
>> from  https://www.softwareverify.com 
>> ,
>>  
>> a pretty powerful and sophisticated program.
>>
>> All other things flagged by this checking application have proven to be 
>> well founded.
>>
>> In the case of the CryptoPP library there appears to be a leak related to 
>> the malloc() at line 77 of dll.cpp.  In addition buried somewhere in the 
>> dll there are instances of attempts to use free() to release memory 
>> allocated by HeapAlloc.
>>
>> There are other memory leaking problems, but the most prevalent are the 
>> two above,
>>
>> Is there any interest here in fixing any of this stuff?
>>
>
> Yes, there's always interest in cleaning up the code, including latent 
> memory leaks. We managed to clear many of them but some are still buried in 
> the library.
>
> If I am not mistaken, the existing leaks are due to use of Singleton. 
> Most of these leaks are clear on Unix and Linux. The problem platforms are 
> OS X and Windows because Apple and Microsoft failed to provide Dynamic 
> Initialization and Destruction with Concurrency [1] in a timely manner. 
> I.e., Dynamic Initialization or "magic statics" as Microsoft calls them.
>
> Singleton is here in case you want to look it over: 
> https://github.com/weidai11/cryptopp/blob/master/misc.h#L305-L316. It has 
> some comments about the problem on platforms like Apple and Microsoft.
>
> If the platform does not offer the primitives we need, then we can't do 
> something stronger than the platform.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm
>
> Jeff
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/b1b4f144-58f9-4f33-aa38-1596b38284b0n%40googlegroups.com.

[cryptopp-users] Re: Fixing confirmed memory leaks in CryptoPP?

[Jeffrey Walton]

On Thursday, September 23, 2021 at 4:01:30 PM UTC-4 activis...@gmail.com 
wrote:

> Hello fellow coders,
>
> I am working on what is intended as a long running crypto comm application 
> written in c++.  As a consequence there can be NO memory leaks.
>
> I've got the CryptoPP library working just fine to sign and verify 
> signatures but there are memory leaks being reported by Memory Validator 
> from  https://www.softwareverify.com 
> ,
>  
> a pretty powerful and sophisticated program.
>
> All other things flagged by this checking application have proven to be 
> well founded.
>
> In the case of the CryptoPP library there appears to be a leak related to 
> the malloc() at line 77 of dll.cpp.  In addition buried somewhere in the 
> dll there are instances of attempts to use free() to release memory 
> allocated by HeapAlloc.
>
> There are other memory leaking problems, but the most prevalent are the 
> two above,
>
> Is there any interest here in fixing any of this stuff?
>

Yes, there's always interest in cleaning up the code, including latent 
memory leaks. We managed to clear many of them but some are still buried in 
the library.

If I am not mistaken, the existing leaks are due to use of Singleton. 
Most of these leaks are clear on Unix and Linux. The problem platforms are 
OS X and Windows because Apple and Microsoft failed to provide Dynamic 
Initialization and Destruction with Concurrency [1] in a timely manner. 
I.e., Dynamic Initialization or "magic statics" as Microsoft calls them.

Singleton is here in case you want to look it over: 
https://github.com/weidai11/cryptopp/blob/master/misc.h#L305-L316. It has 
some comments about the problem on platforms like Apple and Microsoft.

If the platform does not offer the primitives we need, then we can't do 
something stronger than the platform.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm

Jeff

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/864bd052-2ab9-419c-baf4-c0471e3aed9en%40googlegroups.com.