Kent Borg wrote:
> Concatenating two different hashes, for example SHA-1 and MD5,
> apparently does not add as much security as one might hope.
>
> What about more complicated compositions? For example, a reader
> comment posted on Bruce Schneier's blog
> (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html)
> suggests the following:
>
> d1=SHA-1(data)
> d2=MD5(data)
> d3=SHA-1(d1+data+d2)
>
> The final digest would be d1+d2+d3
>
> (where "+" is concatenation)
>
>
> I admit I don't know why this might be significantly better than
> d1+d2, I was hoping someone here would.
>
It's not. It's just backwards compatible with buffer sizes for programs
that already handle SHA-1 (and presumably also MD5) hashes so that less
and smaller changes are required to the code.
It's really quite clever, since the input would have to collide in both
MD5 and SHA1 for it to collide in the final output.
> Concatenating two different hashes, for example SHA-1 and MD5,
> apparently does not add as much security as one might hope.
>
> What about more complicated compositions? For example, a reader
> comment posted on Bruce Schneier's blog
> (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html)
> suggests the following:
>
> d1=SHA-1(data)
> d2=MD5(data)
> d3=SHA-1(d1+data+d2)
>
> The final digest would be d1+d2+d3
>
> (where "+" is concatenation)
>
>
> I admit I don't know why this might be significantly better than
> d1+d2, I was hoping someone here would.
>
It's not. It's just backwards compatible with buffer sizes for programs
that already handle SHA-1 (and presumably also MD5) hashes so that less
and smaller changes are required to the code.
It's really quite clever, since the input would have to collide in both
MD5 and SHA1 for it to collide in the final output.
>
> -kb
>
>
[ reply ]