|
Boost : |
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-12-10 17:30:55
On 12/10/24 19:51, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> I think, HashAlgorithm should allow implementations to use the seed arguments
>> to the hash algorithm constructors as salt, i.e. the constructor would implicitly
>> call update().
>
> No, this is a bad practice and should never be used. As I already said, the
> algorithm should at minimum include the size of the seed, and then pad to
> a multiple of the block size.
Is this something that should be intrinsically supported by
HashAlgorithm, though? Can it be an external component, such as a free
function or an adapter like hmac<>?
Currently, as I look in the hash algorithms provided by Boost.Hash2,
most of them interpret the byte-range seed the way you describe, with
the exception of fnv1a and siphash. fnv1a doesn't append the seed size
(and doesn't pad as FNV-1a is not a block hash); I'm not sure if that's
intentional. siphash has special treatment of the seed if it is exactly
8 bytes. Given these differences, is the user able to have any sort of
guarantee on consistent behavior of the constructors of various
algorithms? If not, why provide the constructor at all?
I think, it would be better if the library provided a standalone
component that would seed any hash algorithm (whether implemented by
Boost.Hash2 or not) in a consistent and secure way.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk