#158: Hash algorithm agility is hard to implement, as specified The problem: Currently (draft 18) 6962-bis refers to the output size of the hash function chosen by a log (denoted HASH_SIZE) as a fixed value:
opaque NodeHash[HASH_SIZE]; Further structs (TreeHeadDataV2, SignedTreeHeadDataV2, ConsistencyProofDataV2, InclusionProofDataV2) then use this definition, which means parsers expect a vector of bytes of fixed length. The difficulty lies in having to know which log the data structure is parsed for before finishing parsing, as it requires parsing just the LogID, looking up the log's metadata by that LogID and continuing parsing according to the size of the NODE_HASH of that log. That is impossible in the case of TreeHeadDataV2 which doesn't even include the LogID (and is not encapsulated in anything that does). Ideally parsing code for parsing all log data would be independent of the hash algorithm chosen for the code (which would extremely simplify implementation in any language I've witnessed, as the TLS deserialization code is in a completely different layer to the signature validation code). Two options: * Force a fixed HASH_SIZE for all logs, say 32 bytes. That may not be silly if that space is deemed sufficient to implement secure hashes with (even if a particular hash function is found to be weak). * Use a variable-length vector for storing hashes. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- [email protected] | [email protected] Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/158> trans <https://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
