We would consider a patch of this nature. There are plenty of platforms where we don’t know and don’t support secure memory. Having customisable hooks would allow them secure memory too.
Yes, is *must* be thread safe — just like the existing implementation. The malloc and free are the important calls. I’m not sure the size and allocated calls are used widely (but it’s worth a check). Secure memory *always* cleanses currently and I don’t see that changing — if something is important enough to put in secure memory, it’s important enough to zero on free. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 5 May 2019, at 11:15 pm, Tobias Nießen <tnies...@tnie.de> wrote: > > Hello, > > I have been experimenting with a custom secure heap implementation recently. > Would OpenSSL be open to a patch that allows users to replace the OpenSSL > implementation with their own, similarly to how CRYPTO_set_mem_functions > works? Based on mem_sec.c, at least sh_malloc, sh_free, sh_actual_size and > sh_allocated need to be pluggable, probably also a new function for > CRYPTO_secure_used. > > Also, should thread safety be part of OpenSSL as it is right now (via > sec_malloc_lock), or should it be up to the implementation? > > Regards, > Tobias >
