Cryptography-Digest Digest #964, Volume #9 Sun, 1 Aug 99 14:13:02 EDT
Contents:
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
([EMAIL PROTECTED])
Re: bits and bytes ([EMAIL PROTECTED])
Re: the defintion of Entropy ([EMAIL PROTECTED])
Re: OTP export controlled? ([EMAIL PROTECTED])
Re: With all the talk about random... ([EMAIL PROTECTED])
Re: Another random question ([EMAIL PROTECTED])
Re: Another random question (Herman Rubin)
Re: With all the talk about random... (Herman Rubin)
Re: With all the talk about random... ("Kasper Pedersen")
Re: SCOTT19U CONTEST UPDATE ([EMAIL PROTECTED])
Re: bits and bytes (Lincoln Yeoh)
Math (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Re: Math (Michael J. Fromberger)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: bits and bytes ("Trevor L. Jackson; III")
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
([EMAIL PROTECTED])
Hash functions chapter from Handbook of Applied Cryptography (Alfred John Menezes)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Sun, 01 Aug 1999 13:44:14 GMT
In article <6bMo3.168$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Peter Seebach) wrote:
> In article <7o027o$u61$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
wrote:
> >C's char != byte.
>
> True in many cases, but not in C or C++. In both language
specs, 'byte' means
> 'char'.
That's not true. There is no definition of 'byte' in ANSI C. sizeof()
returns the length of 'chars' it requires to store the object.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: bits and bytes
Date: Sun, 01 Aug 1999 13:40:59 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > In C there are no standard bit sizes for any types. They must only
> > hold the required data ranges. A 'char' must hold at least -127 to
> > 128 (or vice versa?), an int must hold at least -32767 to 32768, ...
>
> "char" type must be able to accurately represent EITHER 0..255 OR
> -127..127, depending on whether the implementation made it an
> unsigned or a signed integer type. "int" type, which is signed,
> must be able to accurately represent -32767..32767. There are
> also other requirements imposed on the types; range is not the
> "only" one.
Basically it's like this
char, signed char, unsigned char: at least 8 bits
short, unsigned short, signed short, int, ...: at least 16 bits
long, unsigned long: at least 32 bits
signed = signed, unsigned = unsigned
Simple?
> > ... And please stop the bickering.
>
> Much of what you call "bickering" would be eliminated if less
> misinformation were posted.
This is way OT. I would take it to 'news:comp.lang.c' or private email.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: the defintion of Entropy
Date: Sun, 01 Aug 1999 13:52:41 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > If the period of the output is infinit then it's truly random and
the
> > entropy in bits is inifite as well. Simple as that.
>
> Nope. Consider 0101101110111101111101111110...
> This has "infinite period" but is very far from random.
>
Then you are going to say the entropy of a 63-bit LFSR is 2^63 - 1 bits
and I will say you are wrong. Your sequence can be represented with a
few bits. A truly random source is independant and infinite in
length. Maybe I forgot to mention that... oh well.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Sun, 01 Aug 1999 13:48:00 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Well technically you have not supplied a key so it's still useless.
>
> The keys would be provided by the users, as with most computerized
> encryption/decryption programs.
>
But the key is the most important function in a OTP. In this case I
would say sending the key would be a violation.
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: With all the talk about random...
Date: Sun, 01 Aug 1999 13:49:24 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson; III" <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
>
> > > Real random numbers are produced by rolling dice or equivalent
> > > methods.
> >
> > Those are not random either. Consider physics your algorithm...
>
> Where is Knauer when we need him?
>
Well the laws of physics will dictate how a falling dice will land. So
I would say that's not random.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another random question
Date: Sun, 01 Aug 1999 13:46:30 GMT
In article <[EMAIL PROTECTED]>,
"Jeffery Nelson" <[EMAIL PROTECTED]> wrote:
> Here's something to consider. As we know, every computer in the
world (or
> type of computer) processes things at different speeds. Compare a
286's
> compile time (in something such as Turbo C++ 3.0) to a Pentium 233.
This
> makes for interesting possibilities. Say you used your internal
clock to
> seed random numbers. In this was wouldn't the seeds be unique to that
> machine? Or couldn't you make it that way by slowing the PRNG's
iteration
> that slowed it PRN(x) times per loop?
I have absolutely no clue what you are talking about. The time-of-day
thingy most people use
srand(time(NULL))
is highly non-random. It's not even close. It just works fine for
simulations and games. A cryptosystem should be defined outside of the
computer it works on. And no a deterministic PRNG on a 286 will return
the same values as on a 586 ...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Another random question
Date: 1 Aug 1999 09:03:17 -0500
In article <[EMAIL PROTECTED]>,
Jeffery Nelson <[EMAIL PROTECTED]> wrote:
>Here's something to consider. As we know, every computer in the world (or
>type of computer) processes things at different speeds. Compare a 286's
>compile time (in something such as Turbo C++ 3.0) to a Pentium 233. This
>makes for interesting possibilities. Say you used your internal clock to
>seed random numbers. In this was wouldn't the seeds be unique to that
>machine? Or couldn't you make it that way by slowing the PRNG's iteration
>that slowed it PRN(x) times per loop?
This may or may not work. It often depends on how the time is
accessed and stored.
In my opinion, a decent PRNG needs at least thousands of bits
for its initialization, although it is possible that some very
expensive ones might do well with a few hundred. This is not
going to be found in the "random" part of the clock reading,
or even in the entire clock reading, as there are less than
2^17 seconds in a day.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: With all the talk about random...
Date: 1 Aug 1999 09:08:15 -0500
In article <7o1j93$sm6$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> "Trevor L. Jackson; III" <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > > Real random numbers are produced by rolling dice or equivalent
>> > > methods.
>> > Those are not random either. Consider physics your algorithm...
>> Where is Knauer when we need him?
>Well the laws of physics will dictate how a falling dice will land. So
>I would say that's not random.
There are stochastic effects, due to imperfections and thermal
noise, which increase the lack of determinacy. If we roll the
die far enough, quantum indeterminacy in the actions of other
objects will introduce randomness.
Most of the processes being used to generate physical random
numbers work on these principles. I would say that the most
reliable ones are those using quantum effects, such as the
parity of radioactive counts.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Sat, 31 Jul 1999 20:22:34 +0200
Frank Kienast <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
...
> The algorithm went as follows:
> 1) Based on the key entered, generate a hash value between 0 and 1.
> This becomes the seed.
> 2) Multiply this seed by 256 and add to the letter being encrypted in
> the text, "wrapping" if necessary. Actually, I used some smaller nu....
> 3) To generate the next seed, I used an old algorithm I had seen in
> programmable calculator programs years earlier:
> Add PI to the seed. Raise result to 5th power. Chop of whole number
> part, leaving just the decimal part (between 0 and 1) as next seed.
Yes, and the only reason why it works today is because the coprocessor is
the same. It would be REALLY nasty to implement on a system with a slightly
different coprocessor.
/Kasper Pedersen
** I too began fiddeling with DIY algorithms, but that was only 5 years ago.
Of the eleven I still have the source of, none have survived my own attacks.
But I learned some basic stuff that way.**
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: SCOTT19U CONTEST UPDATE
Date: Sun, 01 Aug 1999 14:18:39 GMT
In article <7o1giq$hhm$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> For those who lack the ablility to solve hard problems the Gloat
> contest is down to 40 bits even Dave or Little Tommy boy ought
> to be able to handle it by know by just doing a boring search.
>
Scott why haven't you answered my open questions? should I post them
again?
As long as you don't try to answer my open questions you are proving to
the world you haven't really researched your method. Thus we have
snake oil.
I think it was Bruce who mentioned in AC that anyone can write a 128
round DES variant and make it secure...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: bits and bytes
Date: Sun, 01 Aug 1999 15:44:52 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 31 Jul 1999 19:50:14 GMT, [EMAIL PROTECTED] wrote:
>After recently being pounded on I think I will post this so we can stop
>the bickering about C programming.
>
>A bit is either 1 or 0. Smallest unit given.
>
>A byte is *NOT* 8 bits. If you want to be specific say 8-bits or an
>octet.
>
>In C there are no standard bit sizes for any types. They must only
>hold the required data ranges. A 'char' must hold at least -127 to 128
>(or vice versa?), an int must hold at least -32767 to 32768, etc...
>etc...
But char is not byte. Char is something different. Isn't it strange to talk
about byte and then use char as an example?
And nobody sells stuff by Megaoctets. Or gigaoctets. And I haven't seen
anyone talking about kilooctet files.
And still given the problems figuring out how much is one Megabyte I still
believe that the assumption that byte = 8 works better.
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Subject: Math
Date: Sun, 1 Aug 1999 12:10:27 -0700
In Bruce Schneier's 'Applied Cryptoghrapgy' second edition, third
printing, he talk about RC4 complexity on page 398 first paragraph...
"... RC4 can be in avout 2^1700 (256!x256^2) possiblestates: an
enormous number. ..."
The calculator that I have comes up with 5.62 E 511 for the above
equation in parentheses.
Even if you take into factor the bits of that 256 array it only comes up
to 3.23 E 616 2^2048 ( ie 2 ^ ( 256 * 8 ) ).
Am I missing something here???
Jacques
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: Math
Date: 1 Aug 1999 15:59:51 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED]
(=?ISO-8859-1?Q?Jacques_Th=E9riault?=) writes:
>In Bruce Schneier's 'Applied Cryptoghrapgy' second edition, third
>printing, he talk about RC4 complexity on page 398 first paragraph...
>
>"... RC4 can be in avout 2^1700 (256!x256^2) possiblestates: an
>enormous number. ..."
>
>The calculator that I have comes up with 5.62 E 511 for the above
>equation in parentheses.
>
>Even if you take into factor the bits of that 256 array it only comes
>up to 3.23 E 616 2^2048 ( ie 2 ^ ( 256 * 8 ) ).
>
>Am I missing something here???
If you compute 256! * 256^2, you get (according to GNU bc):
56217945724868536180348175756901261322340369713036369583122392703124\
73084252308041743992693459854350420383402179537038908831805175848609\
22067215508109673120189407122268729367883071624070296082964787277313\
81609647813563352786301843191181300603344183382881259944723983353869\
38050153827654752634923044950884227942008865157673628382230385215000\
66962607462650221834312549140798559454555997436272383820907785920748\
98228095381341656904118528142515629981696000000000000000000000000000\
000000000000000000000000000000000000
It is comparatively trivial to verify that this quantity has 1700
significant figures when written in binary. So the estimate of "about
2^1700" is correct -- although it's really only an approximation. The
actual (exact) number of states is the value given above.
My guess is that your calculator lacks sufficient precision to express
the above equation meaningfully.
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
l3Cto1C2TyxSSXdWLEzhl1zZzifpzqaWYYkeDrLtw0rZKkevcLDSwkQI0T5C0cFPe4fLWoY7
Remove clothing if you want to reply to this message via e-mail.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 1 Aug 1999 05:00:36 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
Date: Mon, 02 Aug 1999 13:16:12 -0400
From: "Trevor L. Jackson; III" <[EMAIL PROTECTED]>
Subject: Re: bits and bytes
Thomas Pornin wrote:
> According to Douglas A. Gwyn <[EMAIL PROTECTED]>:
> > "char" type must be able to accurately represent EITHER 0..255 OR
> > -127..127
>
> I would like to insist on that point: the range is -127..127, not
> -128..127. This is for computers that store signed types with a sign
> bit and the absolute value; this was the case for the PDP-11 (I think,
> correct me if I am wrong). This is rare nowadays since it makes addition
> and substraction a bit more complicated, and it also means that there is
> a 'negative 0' that is not equal to 0 in memory.
The name for this arithmetic ones-complement as opposed to the alternate
twos-complement arithmetic (TCA). PDP-8, PDP-11, LSI-11, DECsystem 10 & 20,
and VAXen all use TCA
> What ANSI says (according to K&R and other sources) is that the integer
> types may represent any number in the following ranges:
>
> char 0 127
> signed char -127 127
> unsigned char 0 255
> short -32767 32767
> unsigned short 0 65535
> int -32767 32767
> unsigned int 0 65535
> long -2147483647 2147483647
> unsigned long 0 4294967295
>
> When you cast a value from a type to another, if the value may be
> represented in both types, then it is conserved. Otherwise the result is
> undefined. When you add or substract or multiply or whatever two integer
> values, the two values are first promoted: the rules here depend on
> the actual sizes of the types.
> If one operand is 'unsigned long', then the other is converted to
> 'unsigned long'.
> Otherwise, if one operand is 'long' and the other is 'unsigned int',
> the 'unsigned int' is converted to 'long' if a 'long' can represent any
> value hold by an 'unsigned int'; otherwise both operands are converted
> to 'unsigned long int'.
> Otherwise, if one operand is 'long', the other is converted to 'long'.
> Otherwise, if one operand is 'unsigned int', the other is converted to
> 'unsigned int'.
> Otherwise, both operands are converted to 'int'.
> [this is from the K&R, 2nd edition]
>
> Special notes:
>
> -- A char is either a signed char or an unsigned char, not a third and
> different type. Usually, a char is signed, but on some platforms (the
> MacIntosh for instance) the char is unsigned (by tradition). If you want
> a signed char, say it explicitely.
>
> -- What happens on overflow for signed types is undefined. Some
> processors have the ability to test the overflow and produce an
> exception if needed (the Intel x86 can do that ['into' opcode] and some
> compilers use that to test the result of each operation). A portable code
> should not depend on what happens on overflow.
>
> -- For unsigned types, it is specified that on overflow, the result is
> truncated modulo a power of two. This is exactly what we need for most
> cryptographic applications.
>
> Back to crypto now. If you want to implement an algorithm in really
> portable C (which is somehow needed if you target embedded systems),
> you should use unsigned integer types, and bitwise 'and' operations
> to truncate each result, like that: (x + y) & 0xffffffffUL. Note the
> 'UL': according to the standards, '0xffffffff' (2^32-1) may not be
> representable by anything else than an unsigned long. Good compilers are
> smart enough to avoid this operation if it is not necessary (gcc, and
> its msdos version djgpp, is smart enough; so is the Sun compiler for
> Solaris, and the DEC C compiler on Alpha stations; other compilers I
> have not checked).
>
> You might also use bit fields. This is a feature of C rarely used, and
> therefore not very optimized in many compilers. However, if you want
> to be portable, that is pretty convenient.
Bit fields are in no way portable, and they are absolutely not
interoperable.. They are one of the first features to avoid when writing
multi-platform software.
> If you seek absolute speed,
> you will produce a more hardware-aware version.
>
> The most often encountered problem of portability is related to
> endianness: I mean, many programmers make some assumptions about the
> layout of variables into memory, and then write four chars and read one
> unsigned int, believing that they would get the first byte as least
> significant byte of the unsigned int. This is a terrible mistake, as
> this means that this code will not work on MacIntosh, Sun stations,
> PalmPilot and other things. Moreover, this reduces readability of the
> code. The above coders usually claim that they do this for speed, but
> this is irrelevant: Intel x86 and m680x0 have opcodes to byteswap large
> integers, and Alpha and PowerPC can read memory in both endianness, on a
> per-opcode basis.
>
> To sum up: if you want portable code, do not even try to guess how
> integer variables are represented in memory, and what are their sizes.
> A portable code can be fast and yet readable. If you require absolute
> speed (I mean, something like twice faster than portable code), then you
> may produce a second version, that makes any hack you want, but this
> version will never be a good sample code. And even then, the endianness
> inherent to the algorithm is irrelevant (I insist on this because
> some of the AES candidates use the little endian representation since
> "it will be faster on the PC"; but this implies some sort of mental
> gymnastic that gives me headaches -- I really prefer big endian, as far
> as human reading is concerned).
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: 1 Aug 1999 16:06:55 GMT
In article <7nvkc9$l7m$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
[ original attribution lost]
>> Oh really. I'm using 5-bit baudot code on a 12-bit CPU with 6-bit
>> characters. An 8-bit byte is useless to me. _*YOUR*_ definition of a
>> byte is not, and never will be definitive. It is probably based on
>your
>> lack of experience with CPU architectures.
>
>But most (around 90%) of public processors are octet based. Most
>microcontrollers and desktop computers use that convention. For
>example if you hooked up a serial port to your processor and a x86 what
>is the length of a character? ...
Somewhere between 5 and 11 bits, depending on what one is doing, and what
one is counting. There are even some _strange_ values like 10-1/2 bits
possible.
ASCII defines a 7-bit character.
------------------------------
From: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: Hash functions chapter from Handbook of Applied Cryptography
Date: 1 Aug 1999 17:02:43 GMT
In the past few months, we have made available 11 chapters
from our "Handbook of Applied Cryptography" for free download
from our web site: www.cacr.math.uwaterloo.ca/hac/
Our publisher, CRC Press, has generously given us permission
to place another chapter on the site. We have just uploaded
Chapter 9 (Hash Functions and Data Integrity).
We continue to negotiate with our publisher to have the
remaining chapters uploaded to the web site.
We hope that these chapters will be of use to people in their
cryptographic work and study. We hope that by making the chapters
available for free download, the book will be accessible to those
who cannot afford to buy it, and to those who may only have a
marginal interest in the material presented in the book. Any
comments in this regard are greatly appreciated.
- Alfred
==========================================================================
| Alfred Menezes | Email: [EMAIL PROTECTED] |
| Department of C&O | Phone: (519) 888-4567 x6934 |
| University of Waterloo| Web page: www.cacr.math.uwaterloo.ca/~ajmeneze |
| Waterloo, Ontario | Web page for Handbook of Applied Cryptography: |
| Canada N2L 3G1 | www.cacr.math.uwaterloo.ca/hac/ |
| Centre for Applied Cryptographic Research: www.cacr.math.uwaterloo.ca |
==========================================================================
------------------------------
** 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
******************************
