Re: Proposal: Addition of a random number generator to GLib

[Kenneth Albanowski <kjahds kjahds com>]

On Wed, 24 Mar 1999, Jeff Garzik wrote:

> Two main points here.  First, I specifically call it a "checksum"
> module because I don't really see serious crypto-heads using Glib for
> their encrypting.  It is intended as a checksum API, not a
> cryptographic hash API, and I think there is a key distinction there.
> I see this as a way of providing checksum capability to reduce
> duplication of effort.

Agreed, however the line is still fuzzy. If you wish to use CRCs
internally for your program, then the "normal" (i.e., most common,
whatever that means) CRC-32 polynomial should be just fine. If you want to
interface with something external, then you may want to provide several
CRCs, or provide a generic interface to compute arbitrary CRCs. At the
very least, you should explain that there isn't just one CRC algorithm. 
(Please see <ftp://ftp.rocksoft.com/clients/rocksoft/papers/> for some 
practically canonical reference material.)

(I'll admit most folks may not care about arbitrary CRCs -- but I've done
enough work with various pieces of equipment using bletcherous serial
protocols that I'll never again be able to pretend there is One True
CRC-32.) 

The crypto-hashes make things a bit more complex, and I'm not positive I
like the complexity. Certainly if they are being used in crypto fashions,
you need to presume a certain half-life for the algorithm -- beyond some
time, it'll be cracked and will need to be replaced. This is true of all
current useful crypto algorithms, of course, and probably will continue to
be true indefinitely. 

Back in our neck of the woods, crypto hash algorithms are very useful for
various hashing and communications purposes (I'll gladly admit to using
MD5 in various capabilities). But I'm not sure whether it's been
mathmetically decided what the quality of MD5 (et al.) is when related to
the normal CRC. Perhaps they aren't really suitable -- perhaps there is an
entire class of data changes that for MD5 yet that make it useless for
normal applications -- but nobody has noticed this yet.  With a CRC, at
least I'm comfortable that we know exactly what it can and cannot do, and
thus feel safe recommending it. To the best of my (limited) knowledge, the
exactly mathematical characteristics of the crypto hash algorithms are
rather weakly known.

> If you draw a line in the sand, creep shouldn't be a problem.  I didn't
> want this to turn into a collection of all the checksum routines
> available.  I would prefer just a couple checksums, one that will fit
> nicely in a machine integer (CRC perhaps), and a high-precision
> checksum (MD5? SHA-1?) for when 32 bits just ain't enough.
> 
> Basically something that provides good coverage for general checksum cases.

On the other hand, practicality will win over philosophical meanderings
any day. :-)

It would seem to make sense to include a standard checksum, a standard CRC
(or perhaps a standard mechanism for invoking an arbitrary CRC polynomial:
if you don't care for it being fast, the math is quite compact, and making
it fast isn't much harder), and the current Big Boys of cryptographic
hashes -- MD4 (for legacy reasons), MD5, and SHA1 -- along with a stern
note that these things shouldn't be used for cryptography or digital
signing. (For a multitude of reasons.) 

_And_ include a note that anyone looking for a flexible crytographic hash
architecture or cryptography should look towards SSL, not Glib.

> > Then again, crypto libraries can be painful to use for political reasons,
> > and there are some fairly common CRC algorithms that will be useful to
> > lots of folks. There are even techniques available for using arbitrary CRC
> > polynomials, which might very well belong in GLib if no other library
> > currently has those facilities. 
> 
> You enumerate here many of the reasons I want to have checksums in Glib :)
> Pulling down OpenSSL just to verify a file's integrity is a bit much...

Agreed. 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)