A few important system's level security features of libnoscrypt I think don't get talked about enough. 1) Noscrypt's core library requires that the callers own the memory the library operates on. This means you have full control over the buffers passed. If using in a modern x86 based operating system, you can add advanced protections, - like locking (mlock) to prevent secret material from being swapped to disk. - You can force populate the TLB and page cache to avoid page faults - You can prevent core dumps of secret data - You can protect the region by preventing writes to it - You can add guard pages (if not already in place by your allocator) The list goes on, but all are useful when holding secrets in your process's memory. Reducing copies of secret data in "unprotected" pages and preventing them from leaking. 2) Noscrypt will never take control of your process. In most cases it will never even make a system call to cause a context switch (with the exception of kernel-level crypto support). - It will not interact with your threading, or process - In most cases it doesn't register any "lifecycle hooks" (exception of openssl > 3.5) such as thread events, process library load events or even signals. - It will never exit(), abort(), fork() etc. These are important for a lot of reasons in crypto - unnecessary context switches can leave cpu caches vulnerable to side channel attacks more than they already are. And taking control of your process can be bad for managed runtimes. If your using a runtime like the Beam VM (elixr), CLR (.NET), JVM (java), a native library that takes control of the process can hurt the stability and security of an application. Many vms require strict management over their resources like threads, ambient data (thread local/fiber local), events, like signals and exception handlers etc. Noscrypt treats this as a high priority, honestly I just hate when libraries crash your stuff when they could have just best-effort cleaned up and returned an error code. 3) Noscrypt core library does not dynamically allocate any memory (with the exception of the openssl backend on some operations) and uses stack allocated automatic variables for the majority of necessary operations, but limits this where possible, preferring pointers to existing memory over copies in all cases. All important stack structures are initialized before use and wiped on best-effort when no longer in use. Stack pages have the advantage of being committed, in the working set, and almost always in TLB. So they are very unlikely (or even impossible on some systems) to trigger a page fault. See also: mlock(), mprotect(), madvise(), mmap(), memfd_secret() - Linux. VirtualAlloc(), VirtualProtect(), VirtualLock() - Windows