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

Right. I have permission from Matt Dillon that we can use his CRC
code as the basis for a GLIB implementation. It currently does
polynomial CRC16 to CRC64. I need to go re-read the CRC reference
material to make sure I don't screw it up when integrating. I should
get some time tonight to work on it.


On 29-Mar-99 Kenneth Albanowski wrote:
> 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 <> for
> some 
> practically canonical reference material.)


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

People are always available for work in the past tense.

Go Bezerk!

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