Dear Dr.Markku,
Thanks for your input.
>>>(H1(x), H2(x)) -- in this case it is sufficient to find a pre-image of H1 or H2 to recover x from the composite hash.
In the use-case we are trying to protect, X is not a secret but is meta-data in a public ledger.
The application layer will recalculate the hash from the provided meta-data. X is well-formed with specific maximum-lengths; it will be verified for correctness at the application layer before hashing; hence the chances of collisions are hopefully lower than, say, if X were to be an arbitrary value with arbitrary lengths.
If one of the hashing schemes is broken in a way that meta-data of two transactions can be created for the same hash (like by a bad actor), then the original one of the two cannot be determined. Hence we were wondering what would be a reasonable hedge against one hashing algorithm broken in the long run.
>>> but I don't immediately see what you gain from truncating H2 in this instance -- especially SHA2-256 to 20 bytes, since the faster, stronger variant SHA2-512 offers a 64-byte output.
Thanks, this sounds like a good idea and we will use SHA2-512 instead of SHA2-256 with truncation.
Trading-off performance heavily for "hopefully" better security, current line of thinking is one of the following:
SHA3-256(SHA-512(X), X)
(or)
SHA3-256(SHA3-256(SHA-512(X), X),X)
Because of an existing system we are forking, the hash has to be 32 bytes long, hence the outer is still SHA3-256.
Our goal is to preserve the integrity of the ledger even in the face of new developments in the long-run like 30 or 40 years from now. Thanks for all suggestions that we are hoping will help achieve this goal.
>>>In any case, such compositions are best analysed using proofs-based argumentation rather than casually as above -- so that the actual security properties gained are well understood. Cryptographers usually do a peer-reviewed publication before even considering using new constructs in the field; IACR FSE / ToSC would probably be the most appropriate venue for that in this instance.
Thanks, we will look into this.
On Wed, May 3, 2023 at 11:58 PM Markku-Juhani Olavi Saarinen <
mj...@iki.fi> wrote: