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

On Wed, 24 Mar 1999, Kenneth Albanowski wrote:
> On Tue, 23 Mar 1999, Jeff Garzik wrote:
> > FWIW, I use checksumming in one form or another very frequently, mostly
> > in applications totally unrelated to encryption and encoding.  I think
> > having MD5 and CRC (at least) in Glib would be very useful.

> The problem is the tendancy to creep: if you have one CRC, then somebody
> will probably want a different CRC, and if you have MD5, somebody will
> want a better cryptographic hash -- MD5 is already partially obsolete in
> any case, and will undoubtedly be completely obsolete some time in the
> future. Presumably the maintainer of the crypto library understands these
> needs and has undertaken the maintenance burden. In that respect,
> duplication of effort is not helpful.

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.

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.

> 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...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]