Why can't long-term private keys be protected, and used solely by, the kernel?
Linux CryptoAPI seems to have an asymmetric key interface[0], RSA signatures are implemented[1], and there's even a x509/ASN1 parser[1]. Shouldn't this be the default on Linux rather than furthering the NIH syndrome with crude library-local allocators? In the very least, shouldn't there be a secure malloc in glibc? If not, why doesn't OpenSSL use an existing secure malloc library[2]?
There have been a lot of posts about the custom malloc. From what i understand, parts of OpenSSL actually depend on the buggy implementation (specifically, the fact that you can the last thing free'd can be malloc'd again).
> If not, why doesn't OpenSSL use an existing secure malloc library?
Any extra library dependency makes OpenSSL less portable. It doubles the work needed to get it running on your new embedded system. shrug It may also increase the code size and attack surface (although probably a good trade-off).
I don't disagree that it sounds like a good idea :).
OpenSSL aims to be cross-platform, so their options are to use kernel-specific cryptography where possible, and a generic implementation where one isn't available; or always use the generic implementation. They probably reasoned at one point that the latter is less work.
Linux CryptoAPI seems to have an asymmetric key interface[0], RSA signatures are implemented[1], and there's even a x509/ASN1 parser[1]. Shouldn't this be the default on Linux rather than furthering the NIH syndrome with crude library-local allocators? In the very least, shouldn't there be a secure malloc in glibc? If not, why doesn't OpenSSL use an existing secure malloc library[2]?
[0] https://www.kernel.org/doc/Documentation/crypto/asymmetric-k...
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
[2] http://www.jabberwocky.com/software/secmalloc/