Implement tari_crypto hashing API: ConsensusHasher::default()

[hansieodendaal]

	Effective GitHub hash: d25d726
#	Reference	Function/Area	Yes/No	URL	URL long
2	base_layer/core/src/blocks/block_header.rs:220	ConsensusHasher::default() [pub fn merged_mining_hash]	No ?	block_header.rs:220	https://github.com/tari-project/tari/blob/development/base_layer/core/src/blocks/block_header.rs#L220
3	base_layer/core/src/blocks/block_header.rs:297	ConsensusHasher::default() [Hashable for BlockHeader]	Yes	block_header.rs:297	https://github.com/tari-project/tari/blob/development/base_layer/core/src/blocks/block_header.rs#L297
8	base_layer/core/src/transactions/transaction_components/mod.rs:97	ConsensusHasher::default() [pub(super) fn hash_output(]	Yes	mod.rs:97	https://github.com/tari-project/tari/blob/development/base_layer/core/src/transactions/transaction_components/mod.rs#L97
14	base_layer/core/src/transactions/transaction_components/transaction_input.rs:370	ConsensusHasher::default() [pub fn canonical_hash]	Yes	transaction_input.rs:370	https://github.com/tari-project/tari/blob/development/base_layer/core/src/transactions/transaction_components/transaction_input.rs#L370
15	base_layer/core/src/transactions/transaction_components/transaction_kernel.rs:193	ConsensusHasher::default() [Hashable for TransactionKernel]	Yes	transaction_kernel.rs:193	https://github.com/tari-project/tari/blob/development/base_layer/core/src/transactions/transaction_components/transaction_kernel.rs#L193
16	base_layer/core/src/transactions/transaction_components/transaction_output.rs:398	ConsensusHasher::default() [pub fn witness_hash]	Yes	transaction_output.rs:398	https://github.com/tari-project/tari/blob/development/base_layer/core/src/transactions/transaction_components/transaction_output.rs#L398

[hansieodendaal]

Hi @AaronFeickert, would using the domain separated hashing API for the above hashes be required? We were debating the issue and would like your opinion. Just search for ConsensusHasher::default() in the code base and you will find where it is used.

ConsensusHasher::default() implements standard Blake2b hashing.

[AaronFeickert]

Using (or perhaps even requiring) domain separation seems like an easy win here, unless there is a compelling reason not to. As discussed with @hansieodendaal earlier, the complexity of consensus hashing for the various underlying structs and types would likely make direct use of the hashing API challenging, and probably unnecessarily duplicate a lot of the existing work on those structs' and types' consensus encodings. A better use of engineering effort may be a thorough analysis of those consensus encodings, in order to be certain they are canonical and cannot lead to malicious or accidental collision.

I did observe several uses of copy_into_fixed_array_lossy in consensus hasher operations, which should be carefully examined. If the input to this function exceeds the given array length, it will be truncated; if the input is shorter, it will be padded with a default element. In both cases, it is generally possible to induce collisions. A safer approach is to either use copy_into_fixed_array (which enforces fixed-length input), or use a safe length prepending in case variable-length input is required.

[sdbondi]

Some context on the copy_into_fixed_array_lossy "hack". This is required because we used a variable length vector type (Vec<u8>) in the block header types and for the Hashable trait where it should have been fixed. Perhaps we should change those types to the FixedHash type and then we can remove copy_into_fixed_array_lossy.

[AaronFeickert]

Some context on the copy_into_fixed_array_lossy "hack". This is required because we used a variable length vector type (Vec<u8>) in the block header types and for the Hashable trait where it should have been fixed. Perhaps we should change those types to the FixedHash type and then we can remove copy_into_fixed_array_lossy.

Yeah, I noticed how the typing was being used in those cases. Agreed that switching to a fixed-length type seems like a wise idea to prevent any future changes that unintentionally introduce collision vectors.

[hansieodendaal]

Implemented with #4522 and #4527