search

mit-dci / opencbdc-tx

A transaction processor for a hypothetical, general-purpose, central bank digital currency
Other
891 stars 200 forks source link

Use domain-separation for hash function invocations #5

Open madars opened 2 years ago

madars commented 2 years ago

Often, a cryptographic system wants to make use of multiple independent random oracles, and when this random oracle is instantiated with the same hash function the security argument breaks down. E.g. Separate Your Domains: NIST PQC KEMs, Oracle Cloning and Read-Only Indifferentiability breaks multiple NIST PQC candidates which reuse the same H(...) for multiple purposes.

I am not aware of any exploitable instances in our codebase, but domain separation is a good practice, especially as the system grows more complex. In general, domain separation is more relevant for computations involving secrets (out of scope for us) or withheld data (definitely in scope for us, as the system maintains minimum data). For a Bitcoin-specific exploitable instance related to the latter one can remember the Merkle tree serialization confusion (this would have been prevented if different layers of the Merkle tree had different random oracles or, equivalently, one committed to the depth in the each hash computation). Domain separation also something people looking at our code will notice and ask about.

@theuni suggested looking at the Schnorr Signature BIP 340, which proposes calculating hash H_tag(data) as H(H(tag) || H(tag) || data). With this choice and when H = SHA256 one can optimize the first block computation.

mriise commented 2 years ago

https://github.com/drand/drand may be of use

HalosGhost commented 2 years ago

@mriise It's not immediately clear to me how drand would be helpful for separating out which hash functions we use for which domains. My reading of it (I have only glanced at it thus far) is that it's a randomness daemon.

I'd be interested in some clarification of what you had in-mind.

mriise commented 2 years ago

My suggestion was towards separating out independent random oracles from each layer and instead rely a "external" (as in separate from the normal network topology) randomness source. Though I don't fully understand details of the cryptographic constructions backing this project and it could be that relying on an external source of randomness would be incorrect altogether.

HalosGhost commented 2 years ago

Gotcha, thank you for the clarification!