Cryptography-Digest Digest #650, Volume #9 Thu, 3 Jun 99 13:13:01 EDT
Contents:
Re: what cipher? (SCOTT19U.ZIP_GUY)
Re: CRC32 ("Amit Ghosh")
Re: Papers on fields, and general number theory (Jim Felling)
Re: Generating Random Numbers (Jim Felling)
Re: ECM factoring question (Bob Silverman)
Is SSL CPU intensive? (Tim)
Re: CRC32 (Doug Stell)
Re: Generating Random Numbers ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: what cipher?
Date: Thu, 03 Jun 1999 13:41:51 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>On Wed, 2 Jun 1999 21:09:19 -0400, in
><[EMAIL PROTECTED]>, in sci.crypt "Particle"
><[EMAIL PROTECTED]> wrote:
>
>>I'm looking for a stream cipher, or a block cipher
>>that works in 8-bit intervals. (actually, I'm looking for
>>the algorithm, I'm planning on implementing it myself)
>>
>>It is very important that the ciphertext retain the length
>>of plain text.
>
If you use the mehods in scott19u which handle any file of over 8 bytes
you can use it to encrypt without changing the length of the file.
If it is important for the ciphertext to retain the exact length.
Any one with a basic understanding of the PC and C should be able to
follow the source code that comes with it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Amit Ghosh" <[EMAIL PROTECTED]>
Subject: Re: CRC32
Date: Thu, 3 Jun 1999 14:41:48 +0200
Hi,
I'm not a crypto/compression guy, so there may be better
answers to your questions, but I do my very best ;-)
1. If I remember it right, crc32 is described in ISO 3309.
2. If you are looking for a faster yet powerfull algorithm,
you may want to try adler32 instead of crc32. You will find
a small description of adler32 in RFC 1950. You may find ZLib
interesting if you're looking for an implementation.
3. Since I'm not an expert on this field of science (see above), I
may be wrong but as I understand, checksum algorithms are
optimized to detect errors in data blocks and not to generate
optimized hash values. You may want to look for hash value
generation algorithms to solve your problem (if I get your
question right). crc32 will most likely not solve your problem!
Hope this helps!
P.S.: Please update your newsreader configuration. Your reply address
is malformed.
--
Amit Ghosh
maito:[EMAIL PROTECTED]
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Papers on fields, and general number theory
Date: Thu, 03 Jun 1999 11:29:58 -0500
Amazon stocks a wide variety of technical references -- try them or Barnes
and Noble
[EMAIL PROTECTED] wrote:
> <snip>
> Thanks for the reply. I will check up some books. Problem is they are
> not sold in my area. hmm..
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: news.groups,at.test,alt.gothic,sci.math
Subject: Re: Generating Random Numbers
Date: Thu, 03 Jun 1999 11:40:25 -0500
Actually nothing so fancy -- all it does is attacks random message
numbers -- it fetches the sender's name, and then
cancels/supercedes/replaces the original message.
Grimace wrote:
> Rochus Wessels wrote in message ...
> >I didn't write this message.
> >And it deleted my original answer, which
> >were two useful references:
> >
> >http://www.counterpane.com/yarrow.html
> >http://www.cs.berkeley.edu/~daw/rnd/
>
> Ah, interesting. I can't remember if it did that originally...
>
> I *think* it's a bot, that stores a big list of genuine posters --
> their names and email addresses, by the looks of it -- and posts
> garbage messages appearing to originate from them.
>
> I know not the purpose. However if it's killed your original message,
> it looks like this is a mildly more sophisticated version of the
> original scam.
>
> Ho and-very-much hum.
>
> -Graeme.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ECM factoring question
Date: Wed, 02 Jun 1999 15:13:37 GMT
In article <7j1ogq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Logic) wrote:
> When doing elliptic curve factorization, we choose an initial point P
on the
> curve. We then calculate the "multiples" of P recursively by
performing the
> group operation on it with a sequence of primes under the chosen
bound B.
> As I understand it, in practice, this sequence is the sorted list of
prime
> powers less than B, where the prime itself replaces each of its
powers in
> the list, e.g. 2,3,2,5,7,2,3,11 and so on.
I don't follow this. Please clarify. One normally computes
M = product(p_i ^ a_i) for p_i < B, and p_i^a_i < H for the first
few primes then a_i = 1 thereafter. Typically H is a few thousand.
One then compute MP where P is the base point.
> In practice, we rarely find a factor in one trial of ECM
(unfortunately).
> Normally we are forced to calculate the multiples of P through the
entire
> sequence. Suppose we instead calculated the multiples of P by each
prime
> until we exceeded B, e.g. 2,2, ... ,2^x<=B, 3,3, ... , 3^y<=B, ...
One computes (say) .... 13^3 (11^5 (7^7 (5^8 (3^12 (2^15 P)))))
You let the powers of the primes decrease as the primes increase.
I do not use prime powers of any primes greater than 1000 in my code,
for example.
> Under the assumption that most trials of ECM yield no factors, could
we not
> gain a slight increase in speed by somehow taking advantage of the
fact that
> we are calculating the same multiple several times (at least for the
smaller
> primes)? Would this make the code simpler as well?
I don't follow you. Please clarify.
See:
R. Silverman & S.S. Wagstaff Jr.
A practical Analysis of the Elliptic Curve Factoring Algorithm
Mathematics of Computation, Jul '93
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tim <[EMAIL PROTECTED]>
Subject: Is SSL CPU intensive?
Date: Thu, 03 Jun 1999 12:48:16 -0400
How CPU intensive is SSL? I would be sending (encrypting with SSL) ~100
bytes of data per second. I have a 68030 running at 20 MHz (embedded
server application) and can allow 20%-30% of the CPU for this task.
Does anybody know of, or where I can get the number of required clock
cycles per byte for SSL?
--Tim
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: CRC32
Date: Thu, 03 Jun 1999 15:29:06 GMT
On 3 Jun 1999 07:54:22 -0000, iLLusIOn
<Use-Author-Address-Header@[127.1]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Hello,
>
> I'm looking for any texts/urls with algorithms and descriptions
> of CRC-32 (like used in zip files for example), I have found a few
> sites providing source code but none which provide really useful
> descriptions of how/why it works. anything appreciated :)
Ross Williams has a great paper, which can be found at:
ftp.adelaide.edu.au/pub/rocksoft/crc_v3.txt
Terry Ritter also has a good writeup on his web page
> are there any ways to speed crc32 up a bit?
Table-driven is CRC is really fast. A copy of the code I have used
several times is attached.
> or are there any faster (yet as "secure") algorithms as crc32? how high is the
> possibility that i'd get the same checksum twice? my
> implementation would be used to generate checksums of many
> files, getting the same checksum on two different files would be
> bad.
You can't get much faster than a CRC, but you shouldn't think of a CRC
as "secure." CRCs are used for error detection, not security.
Any hash function will potentially yield the same result for different
files. The probability is determined largely by the size of the hash
and also by the hash function.
> tia
/* Module: crc.c
* Purpose: Cyclic Redundance Check (CRC) generator/checkers
* CRC-16 (DECnet), CRC-CCITT, AutoDIN-II (Ethernet)
*
*/
#ifdef __cplusplus
extern "C" {
#endif
/*
=====================================================================
This file contains three Cyclic Redundancy Check (CRC) generator
facilitys using three algorithms
a. CRC-16, the 16-bit DECnet CRC
b. AutoDIN-II, the 32-bit Ethernet CRC
c. CRC-CCITT, the 16-bit CRC (better for short data segments)
d. APCO-25 checksum, although not really a CRC.
NOT IMPLEMENTED: The Header Error Control (HEC) field in an ATM
cell
is computed using the polynomial x^8 + x^2 + x + 1 and is the 8-bit
remainder of the 32-bit header after division by the preceding
polynomial.
=====================================================================
*/
#include <stdio.h> /* for NULL */
#include <stdlib.h> /* for malloc */
#include "crc.h"
#define CCITT_GOOD 0xf0b8 /* good result CCITT CRC */
#define AUTODIN_GOOD 0xdebb20e3 /* good result of AutoDIN-II CRC */
/* a good CRC_16 yields ZERO */
/*
=====================================================================
The 16-bit CRC_16 is built upon the following shift-register
reference model. Polynomial: g(x) = 1 + x^2 + x^15 + x^16
-------------------------------------------------------------
|(1) |(x^2) (x^15)| |(x^16)
-->[15] [14]->X->[13] [12] [11] - - - [3] [2] [1]->X->[0]-->X
|
Input data bit 0 first -------
Leading-zero checking is NOT provided by the CRC_16 and it is used
as follows:
1. The crc register is initialized to ZERO.
2. When a crc is appended, it is not inverted.
3. When checking a good message with an appended cec, the
register will return to its initial value of ZERO.
=====================================================================
*/
/* polynomial for bit-wize CRC-16 calculation, using reference model
*/
/* uint16 CRC_16_POLY = 0xa001 ; */
/* table for nibble-wize CRC-16 calculation; smaller table, slower */
/* uint16 CRC_16_TABLE [16] = {
0x0000, 0xcc01, 0xd801, 0x1400, 0xf001, 0x3c00, 0x2800, 0xe401,
0xa001, 0x6c00, 0x7800, 0xb401, 0x5000, 0x9c01, 0x8801, 0x4400,
} ;
*/
/* table for byte-wize CRC-16 calculation; faster, larger table */
uint16 CRC_16_TABLE [256] = {
0x0000, 0xc0c1, 0xc181, 0x0140, 0xc301, 0x03c0, 0x0280, 0xc241,
0xc601, 0x06c0, 0x0780, 0xc741, 0x0500, 0xc5c1, 0xc481, 0x0440,
0xcc01, 0x0cc0, 0x0d80, 0xcd41, 0x0f00, 0xcfc1, 0xce81, 0x0e40,
0x0a00, 0xcac1, 0xcb81, 0x0b40, 0xc901, 0x09c0, 0x0880, 0xc841,
0xd801, 0x18c0, 0x1980, 0xd941, 0x1b00, 0xdbc1, 0xda81, 0x1a40,
0x1e00, 0xdec1, 0xdf81, 0x1f40, 0xdd01, 0x1dc0, 0x1c80, 0xdc41,
0x1400, 0xd4c1, 0xd581, 0x1540, 0xd701, 0x17c0, 0x1680, 0xd641,
0xd201, 0x12c0, 0x1380, 0xd341, 0x1100, 0xd1c1, 0xd081, 0x1040,
0xf001, 0x30c0, 0x3180, 0xf141, 0x3300, 0xf3c1, 0xf281, 0x3240,
0x3600, 0xf6c1, 0xf781, 0x3740, 0xf501, 0x35c0, 0x3480, 0xf441,
0x3c00, 0xfcc1, 0xfd81, 0x3d40, 0xff01, 0x3fc0, 0x3e80, 0xfe41,
0xfa01, 0x3ac0, 0x3b80, 0xfb41, 0x3900, 0xf9c1, 0xf881, 0x3840,
0x2800, 0xe8c1, 0xe981, 0x2940, 0xeb01, 0x2bc0, 0x2a80, 0xea41,
0xee01, 0x2ec0, 0x2f80, 0xef41, 0x2d00, 0xedc1, 0xec81, 0x2c40,
0xe401, 0x24c0, 0x2580, 0xe541, 0x2700, 0xe7c1, 0xe681, 0x2640,
0x2200, 0xe2c1, 0xe381, 0x2340, 0xe101, 0x21c0, 0x2080, 0xe041,
0xa001, 0x60c0, 0x6180, 0xa141, 0x6300, 0xa3c1, 0xa281, 0x6240,
0x6600, 0xa6c1, 0xa781, 0x6740, 0xa501, 0x65c0, 0x6480, 0xa441,
0x6c00, 0xacc1, 0xad81, 0x6d40, 0xaf01, 0x6fc0, 0x6e80, 0xae41,
0xaa01, 0x6ac0, 0x6b80, 0xab41, 0x6900, 0xa9c1, 0xa881, 0x6840,
0x7800, 0xb8c1, 0xb981, 0x7940, 0xbb01, 0x7bc0, 0x7a80, 0xba41,
0xbe01, 0x7ec0, 0x7f80, 0xbf41, 0x7d00, 0xbdc1, 0xbc81, 0x7c40,
0xb401, 0x74c0, 0x7580, 0xb541, 0x7700, 0xb7c1, 0xb681, 0x7640,
0x7200, 0xb2c1, 0xb381, 0x7340, 0xb101, 0x71c0, 0x7080, 0xb041,
0x5000, 0x90c1, 0x9181, 0x5140, 0x9301, 0x53c0, 0x5280, 0x9241,
0x9601, 0x56c0, 0x5780, 0x9741, 0x5500, 0x95c1, 0x9481, 0x5440,
0x9c01, 0x5cc0, 0x5d80, 0x9d41, 0x5f00, 0x9fc1, 0x9e81, 0x5e40,
0x5a00, 0x9ac1, 0x9b81, 0x5b40, 0x9901, 0x59c0, 0x5880, 0x9841,
0x8801, 0x48c0, 0x4980, 0x8941, 0x4b00, 0x8bc1, 0x8a81, 0x4a40,
0x4e00, 0x8ec1, 0x8f81, 0x4f40, 0x8d01, 0x4dc0, 0x4c80, 0x8c41,
0x4400, 0x84c1, 0x8581, 0x4540, 0x8701, 0x47c0, 0x4680, 0x8641,
0x8201, 0x42c0, 0x4380, 0x8341, 0x4100, 0x81c1, 0x8081, 0x4040,
} ;
/*
=====================================================================
The 16-bit CCITT CRC is built upon the following shift-register
reference model. Polynomial: g(x) = 1 + x^5 + x^12 + x^16
-------------------------------------------------------
|(1) |(x^5) |(x^12) |(x^16)
-->[15]- - -[11]->X->[10] - - -[4]->X->[3][2][1][0]-->X
|
Input data bit 0 first -------
The actual implementation contained in the faster, byte-oriented
model of the same algorithm, which uses a table of 256 16-bit
words.
The method of computing the CRC is as follows:
1. XOR input byte with current crc register contents
2. Use lower 8 bits as index into table
3. Right shift crc register 8 bits
4 XOR crc register with content of that table location
Leading-zero checking is performed by the following procedure:
1. The crc register is initialized to 0xffff, rather than zero.
2. When a crc is appended, the 32 bits of the crc are inverted.
3. When checking a good message with an appended crc, the
register
will return to the fixed value, rather than zero.
=====================================================================
*/
/* polynomial for bit-wize CCITT-CRC calculation, using reference
model */
/* uint16 CCITT_POLY = 0x8408 ; */
/* table for nibble-wize CCITT-CRC calculation; smaller table, slower
*/
/* uint16 CCITT_TABLE [16] = {
0x0000, 0x1081, 0x2102, 0x3183, 0x4204, 0x5285, 0x6306, 0x7387,
0x8408, 0x9489, 0xa50a, 0xb58b, 0xc60c, 0xd68d, 0xe70e, 0xf78f
} ;
*/
/* table for byte-wize CCITT-CRC calculation; faster, larger table */
uint16 CCITT_TABLE [256] = {
0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
} ;
/*
=====================================================================
The 32-bit AutoDIN-II CRC is built upon the following
shift-register reference model.
Polynomial: g(x) = 1 + x + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 +
x^12 + x^1 + x^22 + x^23 + x^26 + x^32
====================================================================
| | | | | | |
|
-->[31]->X->[30]->X->[29][28]->X->[27]->X->[26][25]->X->[24]->X-|
|
|
|
-----------------------------------------------------------------
|
|
======================================================|
| | | | |
|
-->[23][22]->X->[21]->X->[20]->X->[19][18][17][16]->X->[15][14]->|
|
|
|
------------------------------------------------------------------
|
|
==============================================|
| | | |
|
-->[13][12][11][10]->X->[9]->X->[8][7][6]->X->[5][4][3][2][1][0]-->X
|
Input data bit 0 first
=======
Leading-zero checking is performed by the following procedure:
1. The crc register is initialized to 0xffffffff, not zero.
2. When a crc is appended, the 32 bits of the crc are inverted.
3. When checking a good message with an appended crc, the
register
will return to the fixed value of 0xdebb20e3, rather than
zero.
=====================================================================
*/
/* polynomial for bit-wize AutoDIN-II calculation, using reference
model */
/* uint32 AUTODIN_POLY = 0xedb88320 ; */
/* table for nibble-wize AutoDIN-II calculation; smaller table, slower
*/
/* uint32 AUTODIN_TABLE [16] = {
0x0, 0x1db71064, 0x3b6e20c8, 0x26d930ac, 0x76dc4190,
0x6b6b51f4,
0x4db26158, 0x5005713c, 0xedb88320, 0xf00f9344, 0xd6d6a3e8,
0xcb61b38c,
0x9b64c2b0, 0x86d3d2d4, 0xa00ae278, 0xbdbdf21c
} ;
*/
/* table for byte-wize AutoDIN-II calculation; faster, larger table */
uint32 AUTODIN_TABLE [256] = {
0x0, 0x77073096, 0xee0e612c, 0x990951ba, 0x76dc419,
0x706af48f,
0xe963a535, 0x9e6495a3, 0xedb8832, 0x79dcb8a4, 0xe0d5e91e,
0x97d2d988,
0x9b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064,
0x6ab020f2,
0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551,
0x83d385c7,
0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f,
0x63066cd9,
0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4,
0xa2677172,
0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa,
0x42b2986c,
0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf,
0xabd13d59,
0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5,
0x56b3c423,
0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2,
0xb10be924,
0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190,
0x1db7106,
0x98d220bc, 0xefd5102a, 0x71b18589, 0x6b6b51f, 0x9fbfe4a5,
0xe8b8d433,
0x7807c9a2, 0xf00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb,
0x86d3d2d,
0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8,
0xf262004e,
0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6,
0x12b7e950,
0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3,
0xfbd44c65,
0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541,
0x3dd895d7,
0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a, 0x346ed9fc, 0xad678846,
0xda60b8d0,
0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c,
0x270241aa,
0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409,
0xce61e49f,
0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17,
0x2eb40d81,
0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6, 0x3b6e20c,
0x74b1d29a,
0xead54739, 0x9dd277af, 0x4db2615, 0x73dc1683, 0xe3630b12,
0x94643b84,
0xd6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0xa00ae27,
0x7d079eb1,
0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d,
0x806567cb,
0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a,
0x67dd4acc,
0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, 0xd6d6a3e8,
0xa1d1937e,
0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd,
0x48b2364b,
0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3,
0xa867df55,
0x316e8eef, 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0,
0x5268e236,
0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe,
0xb2bd0b28,
0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b,
0x5bdeae1d,
0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x26d930a, 0x9c0906a9,
0xeb0e363f,
0x72076785, 0x5005713, 0x95bf4a82, 0xe2b87a14, 0x7bb12bae,
0xcb61b38,
0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0xbdbdf21, 0x86d3d2d4,
0xf1d4e242,
0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1,
0x18b74777,
0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff,
0xf862ae69,
0x616bffd3, 0x166ccf45, 0xa00ae278, 0xd70dd2ee, 0x4e048354,
0x3903b3c2,
0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 0xaed16a4a,
0xd9d65adc,
0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f,
0x30b5ffe9,
0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605,
0xcdd70693,
0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8, 0x5d681b02,
0x2a6f2b94,
0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
} ;
/*
=====================================================================
The CRC generator/checker
=====================================================================
*/
int generateCRC (
uint8 *partIn , /* pointer to input byte string */
int partInLen , /* length of input byte string */
uint32 *crcReg , /* pointer to CRC register */
int algorithm ) /* CRC algorithm to use */
{
int i ;
uint32 index ,
temp ;
if ( CCITT_CRC == algorithm )
{
/* invert crcReg to initialize to 0xffff on first segment or
cancel output inversion on subsequent segments
*/
temp = (*crcReg) ^ 0xffff ;
/* generate the CRC over the entire input */
i = partInLen ;
while ( i-- )
{
index = ( temp ^ (uint32)*partIn++ ) & 0xff ;
temp = ( ( temp >> 8 ) ^ CCITT_TABLE [ index ] ) & 0xffff
;
}
/* invert output to crcReg for appending */
(*crcReg) = temp ^ 0xffff ;
/* check result for return code */
if ( CCITT_GOOD == temp )
return ( 0 ) ;
return ( 1 ) ;
}
if ( CRC_16_CRC == algorithm )
{
/* do NOT invert crcReg, but initialize to ZERO */
temp = *crcReg ;
/* generate the CRC over the entire input */
i = partInLen ;
while ( i-- )
{
index = ( temp ^ (uint32)*partIn++ ) & 0xff ;
temp = ( ( temp >> 8 ) ^ CRC_16_TABLE [ index ] ) & 0xffff
;
}
/* do NOT invert output to crcReg for appending */
*crcReg = temp ;
/* check result for return code */
if ( temp )
return ( 1 ) ; /* non-ZERO residue is BAD */
return ( 0 ) ; /* ZERO residue is GOOD */
}
if ( AUTODIN_CRC == algorithm )
{
/* invert crcReg to initialize to 0xffff on first segment or
cancel output inversion on subsequent segments
*/
temp = *crcReg ^ 0xffffffff ;
/* generate the CRC over the entire input */
i = partInLen ;
while ( i-- )
{
index = ( temp ^ (uint32)*partIn++ ) & 0xff ;
temp = ( ( temp >> 8 ) ^ AUTODIN_TABLE [ index ] ) ;
}
/* invert output to crcReg for appending */
*crcReg = temp ^ 0xffffffff ;
/* check result for return code */
if ( AUTODIN_GOOD == temp )
return ( 0 ) ;
return ( 1 ) ;
}
return ( -1 ) ;
}
/*
=====================================================================
The APCO-25 Checksum generator, not a CRC
The register is initialized to ZERO.
For the n'th input byte, I(n), the generator computes the
following:
C0(n) = C0(n-1) + I(n) mod 256
C1(n) = C1(n-1) + C0(n) = C1(n-1) + C0(n-1) + I(n) mod 256
C2(n) = C2(n-1) + C1(n) mod 256
= C2(n-1) + C1(n-1) + C0(n-1) + I(n) mod 256
C3(n) = C3(n-1) + C2(n) mod 256
= C3(n-1) + C2(n-1) + C1(n-1) + C0(n-1) + I(n) mod 256
=====================================================================
*/
int generateChecksum (
uint8 *partIn , /* pointer to input byte string */
int partInLen , /* length of input byte string */
uint32 *checksum ) /* pointer to Checksum register */
{
int i ;
uint32 byte1 , byte2 , byte3 , byte4 ;
while ( i-- )
{
/* make 4 local copies of the current contents */
byte1 = byte2 = byte3 = byte4 = *checksum ;
/* operate on each byte using the previous byte's new value */
byte1 = ( byte1 + (uint32)*partIn++ ) & 0x000000ff ;
byte2 = ( byte2 + ( byte1 << 8 )) & 0x0000ff00 ;
byte3 = ( byte3 + ( byte2 << 8 )) & 0x00ff0000 ;
byte4 = ( byte4 + ( byte3 << 8 )) & 0xff000000 ;
/* combine the bytes for the new output */
*checksum = byte1 | byte2 | byte3 | byte4 ;
}
return ( 1 ) ;
}
#ifdef __cplusplus
}
#endif
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Generating Random Numbers
Date: Thu, 03 Jun 1999 12:40:27 GMT
<snip>
Using the timing method is not always the best. Since for example in
the PC BIOS the closest clock has a period of 55ms which is not really
usefull.
The closest thing would be a free running counter, but this would depend
on the machine as well as the keyboard handler (if it's dynamic or
follows a clock). Also faster machines will not stay on one value (in
the lsbs) for long, in fact they are much less stable then slower
computers.
Why not check out Yarrow at www.counterpane.com to see how they made a
RNG.
In any case I would try the method, and use some empiracle testing
methods to see if it's 'random enough'.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
