Oddbean new post about | logout
 that's just not true, bitcoin core developers were well aware of the edge cases of memset-before-deallocation for a long time

here's the commit from 2012 that introduces use of OPENSSL_cleanse() instead of memset:
https://github.com/bitcoin/bitcoin/commit/0f8a6477825fbaad0d37233bdd3011d748f607ab

in addition to cleaning up, secure_allocator uses a pool of locked memory to keep wallet keys and such out of swap space

memset, where it is used for cleaning up keys, is used with an extra memory barrier to prevent it from being optimized away. this is the same method used many other libraries such as BoringSSL as well and even the linux kernel 
 Libsecp256k1 not the Bitcoin Core application. I included the compare link you can see for yourself.  
 that commit is an improvement, mostly with regard to stack memory-which tends to be overwritten quickly anyway, secp256k1 doesn't manage dynamic memory

your claim was that we weren't aware of the issue which is just bs 
 I'm very aware of it's edge cases, which is why "insecure" is in quotes.  
 More than anything I would consider it a guard. Initializing stack memory during procedure entry, and after is really a precaution imo. Didn't say it wasn't an improvment, nor makes the previous implementations insecure. Simply calling out the use case. The call did nothing on plenty if not most platforms, yet it was included. The entire point of calling memset at the end of a procedure on stack memory was the intention to clear stack memory, when it was likely NOT doing that at all. 

That's a mistake in my book.  
 yes-mind that the work that was just merged has been underway in three PRs, since at least 2017:

https://github.com/bitcoin-core/secp256k1/pull/448
https://github.com/bitcoin-core/secp256k1/pull/636
https://github.com/bitcoin-core/secp256k1/pull/1579

it took a long time because there's an unfortunate lack of reviewers for any change to secp256k1
i wish people would get involved more instead of criticizing and screaming "bitcoin core devs suck" from the sidelines 
 i would very much like to spend a whole month reviewing that library and porting it to pure Go and inserting some SIMD instructions where relevant 
 Reviewers are not contributors, that's a project issue. It doesn't look like there is a lack of contributions. I don't know what the processes now, but I don't remember it being worth many people's time to become part of the project because if their red tape.

I'm not suggesting Bitcoin-Core developers suck as a whole, most are probably far more intelligent than myself. I'm saying they made a pretty silly mistake that MANY if not MOST other developers make and that took way too long to make it to release (that should have been a patch release). 

I also think criticism shouldn't be stifled for the sake of "if you can do it better, just do it yourself" doesn't fix the problem that everyone else depends on X project and they have obvious problems they aren't fixing etc. 

Could I have worded my original note better, probably, do I think I shouldn't have said anything at all. No.  
 At this point I'm considering vendoring the entire project for noscrypt. I'll have to review open PRs to see what else is missing I could fast-track.  
 go always zeroes memory when allocated. always. always. always.

you should follow this with C allocations