Re: Increasing FreeBSD compatibility in mtree

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> SHA384 is the same as SHA512 except that the initial state is
>> different and 128 of the output bits are thrown away; [...]
> Well, it's the same basic principle as SHA224: you might not have
> space in your message format for the full hash, and it's nice to have
> a method for truncating it which is blessed as safe.

Perhaps, if warm fuzzies (or being able to satisfy a tick-list) are
what matter to you.

But, if just truncating SHA512 to N bits produces something
substantially weaker than any other N-bit hash, then it seems to me
that _necessarily_ indicates a weakness in SHA512....

I don't fully understand the initial state change.  If it makes any
significant difference in the hash strength, that seems to me to
indicate a weakness of some sort in the basic algorithm.  Absent some
kind of nonpublic weakness in the core algorithm (never to be ruled
out, of course), the only reasons I can see are (1) so that SHA384 and
SHA512 of the same data do not have redundancy between them and (2)
paranoia.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B