Support additional hashing functions

[adlerjohn]

Additional hashing algorithms should be added to implementations.

id	name	reason
sha-256d	2-SHA-256	Prevents length extension attacks, and can otherwise leverage the same benefits (e.g. hardware implementations) as SHA-256.
keccak-256	Keccak-256	There are concerns that the changes to Keccak when finalizing it to SHA3 made it more vulnerable.
sha3-256	SHA3-256	SHA3 is the next standard hash function, and unlike SHA2 is not known to be vulnerable to length extension attacks.

[tony-iqlusion]

Note that the implementation is generic over the underlying hash function.

However, I am loathe to support a hash function zoo in any sort of official capacity (beyond enabling the possibility for those who choose to do so).

More choice in cryptographic algorithms increases implementation complexity and harms interoperability. To the extent the existing implementation is generic over the underlying hash function, the main use case is to support hardware cryptographic accelerators for SHA-256 (as one of our main use cases is embedded) as opposed to using the software implementation in the sha2 crate

Length extension attacks against Veriform are largely mitigated through its current use of nested/structured hashing. The one place where there's even a potential for length extension attacks to occur is in toplevel messages, and to me the best solution to that is to place toplevel messages into self-delimiting envelopes which include a length prefix at the beginning of the message, then computing a digest that includes the length delimiter. Not only does this fix the length extension attack potential, but self-delimiting messages are generally convenient and it's exceedingly common to wrap Protobuf messages this way already.

That said, I do like sha256d since having seen it first used in Tahoe-LAFS, and will note that they did use it in the computation of their Merkle trees (as did Bitcoin/Satoshi, probably because that's what Tahoe-LAFS did). It just feels redundant in that context.

[adlerjohn]

However, I am loathe to support a hash function zoo in any sort of official capacity (beyond enabling the possibility for those who choose to do so).

You're not wrong, but that seems contradictory to officially supporting multiple languages:

NOTE: Veriform is a multi-language monorepo: all implementations in all languages within the repo are intended to implement the spec in its current state and share a consistent feature set. The progress above applies equally to all language implementations currently within the repo.

So long as a specification exists, it can be implemented in any language.

[tony-iqlusion]

I would suggest implementations in other languages are similarly parameterized around the underlying hash function.

Eventually it'd be good to pick an alternative to SHA-256 as a failsafe (or potential performance optimization), but initially I think it'd be better if all implementations use SHA-256.