Re: Bug#325205: please provide sha256sum, sha384sum and sha512sum

[David Madore]

On Sat, Aug 27, 2005 at 04:30:51PM +0000, Eric Blake wrote:
> Would it make more sense to have a single sha utility that takes
> an argument of which algorithm to use, defaulting to the most
> secure, then the user can define wrappers to invoke a non-default
> algorithm?  For example, 'sha --algorithm=sha224' or 'sha --224'?

That's the OpenSSL/GnuPG approach, but IMHO coreutils shouldn't work
that way (not for hash algorithms at least).  For one thing, the
64-bit code in sha384/sha512 might involve using external libraries
that gcc might automatically link in on certain platforms, and I don't
think we want that creeping in md5/sha1/sha224/sha256.  It's true that
it might be useful having a utility that can check any digest
whatsoever (automagically detecting it based on its length); though
that would no longer work if someone adds ripemd160 to the list, and
I'm not sure it's a good habit to let users take not to flag their
hashes correctly.

Incidentally, it's not clear which is the "best" hash to take (it
certainly depends on what you want to do with it): on a 32-bit machine
(unfortunately still a very common case...) sha384 and sha512 are
horrendously slow; also, sha224 and sha384 have the advantage of not
being "extensible" (you can't compute hash(x||y) knowing hash(x) and
y), the latter property being sometimes viewed as a security problem
in md5/sha1/sha256/sha512 (they disclose the full internal state in
the hash).  Again, it depends what you're trying to do with the hash,
and certainly the utility can't guess that.  Since each hash has its
own specific niche, I would advocate leaving the utilities as separate
programs.

Happy hacking,

-- 
     David A. Madore
    (address@hidden,
     http://www.madore.org/~david/ )