[rb-general] rb formalism

[Daniel Shahaf]

Bernhard M. Wiedemann wrote on Wed, 19 Dec 2018 11:29 +0100:
> On 18/12/2018 15.44, Eric Myhre wrote:
> > I think it's fairly open to interpretation.  Implementing it as
> > h(h(➡),■) would be more or less the same semantics, no?
> 
> you could even use h(h(➡),h(■))
> so that you only have to hash ■ output data once.
> A bit like .buildinfo files
> or foo.tar.xz.sha256.asc signatures

I think discussing how to implement a hash function in terms of other
hash functions is nothing more or less than rolling one's own crypto,
and as such falls under "Don't try this at home".

I suppose someone of you might be surprised by that.  The issue here is
that in general, you can't combine cryptographic primitives in arbitrary
ways and expect the result to be secure, unless that has been specifically
proven.

Hash functions are usually defined in terms of collision resistance.
The constructions above have not been proven to be collision resistant,
and moreover, they might not *be* collision resistant — even if h() is.
Therefore, we should assume they are not collision resistant.

Cheers,

Daniel