Yup. That works. Just don't forget the follow-up, where external feedback is crucial. Shameless plug: I've written my own crypto library¹. Not just for the lulz, I fully intend to use it in production. To do that, I had to disregard the crypto community, that basically says anyone who does that deserves to burn in Crypto Hell the time it takes them to count to 2^256. (I might exaggerate a tad). They say that for a re…
I am just curious, how much effort went into side channel mitigation, etc? There are a lot of things libsodium does to mitigate side channels that aren't obvious or documented.
Very little. The chosen primitives are naturally resistant to timing attacks, thanks to the utter absence of secret dependent branches and secret dependent indices. I did have doubts about constant time comparison (code generated under -O3 was crazy), which I solved by changing the API.
Locking the memory is not implemented, only discussed in the manual (Monocypher wants to stay portable).
Zeroing out memory is neither implemented nor discussed. I'm not sure what to make of it, actually. If it is useful, then wiping the contexts is not enough, you likely also have to wipe temporary buffers above the top of the stack (I don't think anybody does this). In any case, if the attacker can read your memory, you're probably screwed anyway.
Now if some attacker can read your memory only after you've processed your secret stuff, a `crypto_wipe()` function would have its uses. But if you've processed secret stuff once, you're likely to do it again, and then crypto_wipe won't save you.
I'm also afraid zeroing out memory gives a false sense of security. I'm more in favour of segregating the sensitive stuff in a separate process, like Qmail.