I've pointed this problem out early last year to libsodium, but they chose to ignore it.
My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.
My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.
I'm guessing you're referencing this [0]. libsodium's response that your suggestion wasn't enough seems reasonable, as does their response:
> `sodium_memzero` should be considered as best-effort, with reasonable tradeoffs.
The documentation for memzero [1] doesn't read like it works 100% of the time, no matter what. It reads like there are tradeoffs involved.
> My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.
Your memset_s also doesn't work on big endian, whilst "the so-called 'secure' libs" often do.
I'm fine with self-promotion, but don't disparage efforts that have a much larger surface that they deal with, simply because you disagree with the tradeoff they find acceptable. A one-liner isn't enough for that conversation.
[0] https://github.com/jedisct1/libsodium/issues/802
[1] https://download.libsodium.org/doc/memory_management#zeroing...
I don't see anything that suggests you did have an idea about "upcoming cache exploits", so I'm afraid I can't say that you were.
I saw you mentioning something that would help, but was nowhere near enough, to deal with Spectre, which was then dealt with by microcode, kernels and every other part of the software stack, making attacking libsodium with Spectre something that might not even be possible.
> The tradeoff they are talking about is leaving secrets in the cache, because mb(lb) is slow. This is not acceptable for security, only for performance.
Not entirely. The main reason is this one:
> SPECTRE-like attacks can be conducted during all the time the secret is present, prior to zeroing. The required preconditions and the time window during which a full memory barrier could help, seem to be negligible compared to the actual lifetime of the secret.