Vinnie Falco wrote:

On Mon, Dec 9, 2024 at 10:50 AM Peter Dimov mailto:pdimov@gmail.com > wrote:

Note that reaching a multiple of block_size is important, because it ensures that the secret key you passed as the seed is not left in the internal buffer of the hash algorithm, visible in memory dumps.

Is hardening against memory dumps in scope for this library?

That's a pretty basic quality of implementation issue in this domain. High quality is always "in scope" for Boost libraries.

Is this documented?

No, I don't think it is.

Claudio DeSouza wrote:

The common practice here is to have a specific allocator that safely memsets things to 0, and in a way that is guaranteed that an optimiser won’t just remove it.

I have no idea what you're replying to, but anyway... There's no reliable way to implement a "secure memset" (that doesn't impede performance) without compiler support. There is this https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1315r7.html https://github.com/cplusplus/papers/issues/67 which seemingly got into C23 as `memset_explicit`, so C++ will also get it at some point, and hopefully compilers will implement it as __builtin_memset_explicit, available in all standard modes. As is, compilers remove the memset if they can see the object is being immediately destroyed afterwards, which in our case may be an issue for one shot hashing leaving part of the message behind, but it's typically not going to be an issue for the seed constructor leaving the seed behind, because the hash algorithm object is rarely being destroyed immediately after construction. Either way, we are aware of the need of using secure memset.