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

[David Madore]

On Sat, Aug 27, 2005 at 10:59:06AM +0200, Jim Meyering wrote:
> David Madore <address@hidden> wrote:
> > sha256, sha384 and sha512 are the generally advocated replacements.
> > They should be made available in coreutils (certainly there are other
> > implementations available, but it is essential that they be at least
> > as widely available as md5sum was, if they are to replace it).
> >
> > So, please implement sha256sum, sha384sum and sha512sum as part of
> > coreutils, either in Debian or by forwarding upstream.  I can provide
> > a patch for this if it is useful.
> 
> Thanks for the offer!
> If you can also sign a copyright assignment and have the
> energy to prepare a clean patch, I (upstream) am interested.

Yes, I am willing to do that.

> My requesting a `clean' patch means we're pretty picky,
> and that the more of the following you can do, the better.

Can I ask you to take a look at the attached patch?  It is not yet
satisfactory (at least, it needs to be forwardported to the CVS
version, as I worked against 5.2.1 because I wanted to install this
ASAP on my Debian boxen), but maybe we can start from this to discuss
what needs to be done.  It implements sha224, sha256, sha384 and
sha512.

[Note: need to "chmod +x tests/sha???sum/basic-1" after applying.]

Here are a few things which need to be said about it, and which may be
concerns:

- sha224 and sha256 (in lib/sha256.c) present no particular
difficulties.  However, as concerns sha384 and sha512 we have the
following problem: the algorithm uses 64-bit words.  The attached
patch (in lib/sha512.c) tries to find a 64-bit unsigned integer type
basically by copying the code from md5/sha1 and adding a test for
unsigned long long (and it barfs if it can't find one): however, this
is probably not portable enough for your goals.  It should be possible
to write an implementation of sha384 and sha512 using only 32-bit
words, but that would be extremely tedious, so I might be willing to
do it, but not immediately.  In the meantime, I guess one needs to
have some configure test determine whether 64-bit words are available
and, if not, warn the user and skip compiling sha384 and sha512.  Only
I don't know how to do that, so I'll need some help here.

- Speaking of word sizes, there's a potential alignment problem in the
common code in src/md5sum.c, which does not seem to check whether the
result buffer is 32-bit aligned (let alone 64-bit).  This should be
trivial to fix, if that's an issue: but someone should decide whether
the fix goes in the library routines (remove alignment constraint) or
in the md5sum common code.

- sha1sum does not seem to be documented in texinfo (at least not in
5.2.1), so, since I was lazily copying everything I could from sha1, I
didn't come up with a texinfo doc for sha224 etc.  I'm willing to try
to document sha1sum along with the rest (but I've never written
texinfo, I hope that's not a problem).

- With respect to the following remark of yours:

> By the way, your e.g., src/sha256sum.c file should look like this:
> 
>   #include "checksum.h"
>   int algorithm = ALG_SHA256;

I tend to disagree with the way it's done: currently src/md5sum.c is
the common code of md5sum and sha1sum (and potentially all others) and
it links against src/md5.c and src/sha1sum.c to provide the
"algorithm" variable which is then checked _at run-time_ to decide
which algorithm to use.  With due respect, I think this is terribly
ugly because it means the full code of every hash algorithm will be
included in each of the utilities: there's no way it can be optimized
away (if we include sha384 and sha512, this is a problem because, as
mentioned above they might not be always available).  And since the
"algorithm" variable cannot ever be changed (for example, there's no
command-line switch to make md5sum act like sha1sum or vice versa!),
this way of doing thinks seems pointless.

So I'd like to advocate doing things differently, as in my attached
patch: do away with src/md5.c, src/sha1sum.c and src/checksum.h, and
simply compile src/md5sum.c six times, with a different compile-time
flag each time, to provide the six utilities.  This works fine in
automake, it means recompiling the same source six times but the
resulting utilities are smaller and do not contain any needless code.
How does that sound?

- Lastly, as concerns tests, I used the FIPS-supplied test vectors,
except that I did not include the "one million a's" test, because I
don't know how to do this properly with Fetish (we don't really want
to write a file with one millon a's in it just to test the utility: it
would be much better to pipe the data, but I don't know the framework
for that).

That should be all.  I'm sure we can settle this very soon.

Happy hacking, 

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

coreutils-5.2.1-sha2.patch
Description: Text document