-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Client should not require Block hash to be H256 for everything useful #3624
Comments
@andresilva pointed out that somewhere We should aim to make this more flexible with some kind of conversion parameter or drop the requirement entirely. |
I'm confused.. Isn't H256 exactly what avoid the type parameter everywhere? |
@burdges This line substrate/core/client/src/client.rs Line 301 in 203e2c2
|
Well, I suppose in some sense it's avoiding a concrete specification of the hash algorithm, but Substrate in some places says "we're generic over the hash output length" and in most (important places) it says "the hash length must be 256 bits". |
I see.. We need 256 bit hashes for 128 bits of security anyplace where birthday attacks pose a threat, like in Merkle trees. We can safely neglect that we technically loose some security bits from the Merkle tree itself, so we do not afaik require more than 256 bits anyplace. As an aside, if we identify places that only require fewer bits of security, like MACs, then we could make them use some |
It should either be fully-generic or fully-non-generic, not some weird halfway-house. |
I'm saying non-generic H256 is always fine. :) |
Right - and just to clarify, any cryptographic non-safety caused by too-small hashes is not something that would arise as part of the implementation of this issue. That would happen in the chain configuration, where somebody might choose a hash size which is too small. |
IMO, a better option would be to have a |
DOne |
This pollutes everything.
When we need to use hashes as keys on disk, I think it would be fine to truncate hashes to 256 bits silently and internally (as that is more than enough entropy), but not to require it as a type parameter everywhere.
The text was updated successfully, but these errors were encountered: