[OPEN-ILS-DEV] PATCH: SHA1 using GNUTLS

[Scott McKellar]

--- On Thu, 12/24/09, Jason Stephenson <jstephenson at mvlc.org> wrote:
> Attached is a patch against OpenSRF trunk that replaces the
> body of sha.c to use the gnutls_fingerprint() function.
> 
> I did not make any changes to md5.c because the public
> interface in md5.h looks a bit more complicated than used by
> sha.h: 3 functions vs. 1. Replacing the md5 implementation
> with something that uses gnutls_fingerprint(), I leave as an
> exercise for someone more familiar with that part of the
> code than myself.
> 
> The patch builds on our test system, which is Ubuntu Hardy
> Heron.
> 
> GNUtls is LGPL, so avoids the licensing issues of OpenSSL.
> 
> Cheers,
> Jason

Thanks for the Christmas present.

I've taken a look at the code but I haven't tried to run it.  So far
it doesn't look like a drop-in replacement for the present shahash(),
for two reasons:

1. It returns a 20-byte binary buffer (plus terminal nul) rather than
a 40-byte hex string (plus terminal nul).

2. It returns a pointer to a dynamically allocated buffer, that the
caller needs to free, instead of a pointer to a static internal buffer.
This is arguably a better design but will leak memory unless the calling
code is changed accordingly.

Both of these issues can be readily resolved.  You've done the main
legwork and I can do the rest.  Instead of overwriting shahash()
directly I shall probably create a new function with a different name,
and replace each call one at a time.

As for MD5: I think the reason that's a little messier is that the
existing code is designed for incremental hashing -- you feed it a
series of chunks, and get the final result after the last chunk.

In practice, we only feed it one chunk at a time anyway, in the function
md5sum (in utils.c).  For our purposes we can probably use the same
approach for MD5 that you have used for SHA1.

It may be a while before any of this shows up in trunk.  For one thing,
I want to take at least a cursory look at the gnutls source code to
look for portability issues.  Then there's testing.  but it will get
there, barring unexpected problems.  Thanks again.

Scott McKellar