Re: [boost] [Hash2] Result extension
Vinnie Falco wrote:
Sigh.. copy/paste typo.
/** Return a seeded HashAlgorithm */ template< class HashAlgorithm > HashAlgorithm make_seeded( unsigned char const* seed, std::size_t n ) { if constexpr(std::is_constructible<HashAlgorithm, unsigned char const*, std::size_t>) return HashAlgorithm(seed, n); else { HashAlgorithm h; hash_append(h, seed, n);
You can in principle do something like that (except fix it to compile) but (much) better practices would be - hash.update( seed, n ) - encode `n` as 64 bit little endian in 8 bytes - hash.update these bytes - hash.update( "\x80", 1 ) - hash.update( "\x00", 1 ) - hash.update with as many zeroes as needed to reach a multiple of HashAlgorithm::block_size That's, incidentally, exactly what `update(p, n); result();` does. (What an amazing coincidence.) 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. The test https://github.com/pdimov/hash2/blob/develop/test/plaintext_leak.cpp tries to catch these mistakes. That's why this line https://github.com/pdimov/hash2/blob/7a25f8518692b657e9272884519519fbaca2ec5... is needed, for example.
return h; } }
Thanks
On Mon, Dec 9, 2024 at 10:50 AM Peter Dimov <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? Is this documented? Thanks
Vinnie Falco wrote:
On Mon, Dec 9, 2024 at 10:50 AM Peter Dimov <pdimov@gmail.com <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.
On Mon, Dec 9, 2024 at 11:06 AM Peter Dimov <pdimov@gmail.com> wrote:
That's a pretty basic quality of implementation issue in this domain.
High quality is always "in scope" for Boost libraries.
If it is in scope then should it be documented, with an analysis of attack vectors and how the library mitigates them? And should there be guidance for users, who also need to make sure they handle keys in ways that do not subvert the security guarantees of the library? Thanks
On 12/9/24 21:49, Peter Dimov via Boost 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.
The test
https://github.com/pdimov/hash2/blob/develop/test/plaintext_leak.cpp
tries to catch these mistakes.
That's why this line
https://github.com/pdimov/hash2/blob/7a25f8518692b657e9272884519519fbaca2ec5...
is needed, for example.
Plain memset may be optimized away by the compiler. If you want to guarantee this data doesn't leak, a secure memset should be used.
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.
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.
participants (4)
-
Andrey Semashev -
Claudio DeSouza -
Peter Dimov -
Vinnie Falco