Cryptography-Digest Digest #216, Volume #13 Fri, 24 Nov 00 05:13:00 EST
Contents:
Re: DES question: Has this ever been proven before? (David Wagner)
Re: A Simple Voting Procedure (Dan Oetting)
Re: vote buying... (David A Molnar)
Re: vote buying... (David A Molnar)
Re: Isomorphic Elliptic Curves ("John A. Malley")
Re: DES question: Has this ever been proven before? (Francois Grieu)
Re: Man arrested in stolen Enigma case (Francois Grieu)
Cyrptography Digest Archive ? (Mark Harrop)
Re: DES question: Has this ever been proven before? (Francois Grieu)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: RSA Signature ! (Francois Grieu)
Re: My new book "Exploring RANDOMNESS" ([EMAIL PROTECTED])
Re: Man arrested in stolen Enigma case (Richard Heathfield)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: DES question: Has this ever been proven before?
Date: 24 Nov 2000 05:02:45 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Paul Crowley wrote:
>Better yet, use the techniques of
>
>Paul C. van Oorschot and Michael J. Wiener.
> Parallel collision search with cryptanalytic applications.
> Journal of Cryptology, 12(1):1-28, 1999.
>
>This finds collisions in a function f() by iterating f(), hugely
>reducing memory requirements. If we can avoid using the disk
>altogether, it should be much faster.
>
>David Wagner, ISTR you demonstrated this by finding collisions in the
>Unix password hashing function. Do you still have source for that, and
>is it available online?
I seem to have misplaced the source, but an example of the results may
be found at <http://www.cs.berkeley.edu/~daw/my-posts/crypt-collision>.
However, it was very easy to implement. Basically, you pick a set of
distinguished points (e.g., the 64-bit blocks whose low 20 bits are all
zero), then you iterate f() at high speed until you hit a distinguished
point. When you see a dist. pt., you enter it into some central table,
and then continue iterating. When you encounter the same dist. pt. twice,
then you've found a collision in f(), which is exactly what you wanted
to find. By storing the iteration count along with each distinguished
point in the central table, once you see a collision you can backtrack
to find the two pre-images that map to the same output.
------------------------------
From: Dan Oetting <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Thu, 23 Nov 2000 22:16:15 -0700
In article <[EMAIL PROTECTED]>, David Schwartz
<[EMAIL PROTECTED]> wrote:
> Stanley Chow wrote:
>
> > Properties under discussion:
> > p1) voter can prove, by himself alone, at his sole option, that
> > his vote is or is not correctly counted
> > p2) voter can be forced to reveal his vote against his will
> >
>
> The voter is displayed a GUID before he or she votes which he may or
> may not write down. He then casts his vote. Immediately after the
> election, all the GUIDs are released along with which way they voted. At
> the same time the voter votes, he is shown one GUID (that is not his)
> that was cast (by someone else) for each other candidate, which he may
> or may not write down.
>
> Why doesn't this meet 'p1' without providing 'p2'?
If the system is rigged, the alternate GUID's could be selected from a
small pool known to the atacker.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: 24 Nov 2000 05:04:14 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> All the attempted solutions I've seen fail to solve the problem that
> voters' authentication credentials can be bought. (Authentication
> credentials are whatever a voter knows or has that proves that they
> are eligible to vote, and that distinguishes them from another voter -
> e.g. keys or smartcards.)
What do you think of making the credentials sufficiently important for
other things as well that they're too expensive to buy in bulk? e.g. the
credential allows voting, but it also allows access to a bank account, so
you need to pay someone his bank balance or more before he'll give it up.
This is only a partial solution, but it seems better than nothing.
It seems to be the approach Brands takes in parts of his book on
credentials. But I shouldn't speak much about that until I've read more of
it.
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: 24 Nov 2000 05:35:56 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
>>One thing that I do find interesting about the Presidental election
>>system is the lack of preferental voting.
> Maybe only a cynic would point out at this point that the two major
> parties have an interest in keeping the current system the way it is,
> but I guess noone will dispute that preferential voting does give
> third parties more power, for better or for worse.
Does it matter that actually determining the winner given the votes
is slightly more complicated for preferential voting? What do countries
with preferential and transferable voting do for hand recounts?
The Undergraduate Council elections at Harvard use Single Transferable
Vote as a voting system. One election, the tabulating software died
mysteriously while trying to evaluate the results of the Presidential
election. The problem was traced to voters which had submitted ballots
with only write-in votes -- the write-ins were eliminated as not
contributing any votes, and then the ballot looked like a
"null" ballot. Hello untested case!
I wasn't there, but I heard that it took several hours to figure out just
what the hell had happened. A scarier prospect is a bug in the software
which caused it to misapply the STV algorithm. Once the software is called
into question, what do you do?
At least with a majority-wins election system, a hand recount is fairly
straightforward. The only computation involved is tallying and a
comparison. More complicated schemes seem potentially more prone to
error; while they're checkable errors, the problem is if an error goes
undetected until after the election period is over...
-David
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Isomorphic Elliptic Curves
Date: Thu, 23 Nov 2000 23:13:04 -0800
"J. Rostand" wrote:
>
> Two very simple questions:
>
> Let E1 and E2 be two elliptic curves over a finite field K (defined as
> cubic curves in the projective plane).
>
> 1) What is the definition of E1 being isomorphic to E2?
> 2) What is the relation between that isomorphism and the algebraic
> structures of the underlying groups? For example, are the groups of E1
> and E2 isomorphic if and only if E1 and E2 are isomorphic?
Two elliptic curves are isomorphic if their group structure is the same.
This occurs when there is a rational, invertible transformation (x,y)
|-> (x',y') such that the point (x,y) is on the first curve iff the
point (x',y') is on the second curve. The two elliptic curves
E_a,b(F_p) and E_c,d(F_p) are isomorphic over the same ground field F_p
if and only if c = a*A^4 and b = d*A^6 for some A that's an element of
F_p.
The notation E_a,b(F_p) means an elliptic curve of the form
y^2 mod p = ( x^3 + ax + b ) mod p.
Got this from Lemma 6.4 of Chapter 6 of Dr. Burton Kaliski, Jr. 's
Thesis "Elliptic Curves and Cryptography: A Pseudorandom Bit Generator
and Other Tools", MIT, February 1988. He references a paper by J. Tate,
"The arithmetic of elliptic curves," Inventiones Mathematicae,
23:179-206, 1974.
Furthermore, as I understand it (and I am new to this, still reading Dr.
Kaliski's thesis with a copy of "Rational Points on Elliptic Curves" by
Joseph H> Silverman and John Tate on hand, ISBN-0-387-97825-9), two
elliptic curves E1 and E2 can be isomorphic to an extension of the field
F_p without being isomorphic to each other over the field F_p.
Hope this helps,
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 24 Nov 2000 08:22:41 +0100
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Better yet, use the techniques of
>
> Paul C. van Oorschot and Michael J. Wiener.
> Parallel collision search with cryptanalytic applications.
> Journal of Cryptology, 12(1):1-28, 1999.
I stopped my subscription to the JC in late 1998 but found a free
online abstract at
<http://link.springer.de/link/service/journals/00145/bibs/12n1p1.html>
> This finds collisions in a function f() by iterating f()
> hugely reducing memory requirements. If we can avoid using
> the disk altogether, it should be much faster.
Paul is perfectly right, and the non-parallel version of the
collision search by cycle-finding is easy enough to guess.
The key ideas are that
- should we enter a cycle when computing X, f(X), f(f(X))...
there is one collision at the point we enter the cycle,
and this is expected after roughly 2^32 iterations when f()
is a random function with a 64 bit result.
- we do not need much memory to detect that we have entered
a cycle and locate it approximately.
- then it is easy to pinpoint the entry point in the cycle,
thus the collision.
I think it works as follows:
- Starting from some X<0> we'll compute the X<n+1> = f(X<n>)
[DES_K(X<n> ^ X<n>) in our case] while keeping in RAM a short
table of the previously computed X<n> when n is a multiple of
say 2^20, together with a pointer to X<n-2^20> [NULL for n=0];
using a classic hash-code technique, we'll keep the table
quickly searchable using key X<n>; in our case the table fits
in RAM, and even in L2 cache RAM for agressive choice of
the parameters.
- Compute the X<n> and search each one in the table; if no match
is found, enter X<n> in the table if n is a multiple of 2^20
and proceed until a matching X<n> is found.
- Backtrack to the previous n multiple of 2^20 on each side
(following the pointer in the table on one side, and the
previously entered value on the other) then find a collision in
at most 2^21 extra iterations of f(); just compute up to the
next 2^20 values on each side and enter the whole stuff in
a RAM table [the case of short cyles is covered].
The only "drawback" I can think compared to my previous technique
is that the X and Y found by cycle-finding look random, when mine
tend to be 0 (or some choosen value) in the left half.
It still seems possible to use a bitsliced DES implementation
[at some expense in memory or work in the final step]
but this does not even seem necessary for a single search: at
a modest 2e6 DES/second it should be less than 1 hour !
Again, who will be the first to give distinct X and Y such that
DES_K(X) ^ X = DES_K(Y) ^ Y for K = 0123456789ABCDEFh ?
I hardly see any practical use in the thing. If we are after
special properties of DES (more or less collision than for a
random function) we should also try to cancel the final swap
in DES, which is equivalent to swapping adjacent bit pairs in
the cyphertext, but it still looks hopeless for a random K.
What about first investigating the cycles in
f(X) = BitSwap(DES_K(X)) ^ X for K = 01FE01FE01FE01FEh ?
It seems less unlikely to get at some new result (I can't spot
a published property of DES with semi-weak keys seen as a black
box).
Francois Grieu
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Man arrested in stolen Enigma case
Date: Fri, 24 Nov 2000 08:27:18 +0100
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> Francois Grieu wrote:
> > source: <http://www.bletchleypark.org.uk/press.htm>
>
> Old news. Did you not see the article I posted on Saturday
> afternoon, under the heading "Enigma Development"?
Sorry, missed your post (now I got it). Still my source is new.
And repetition is the essence of Usenet.
Francois Grieu
------------------------------
Date: Fri, 24 Nov 2000 19:00:13 +1100
From: Mark Harrop <[EMAIL PROTECTED]>
Subject: Cyrptography Digest Archive ?
--=====================_15684435==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi all...
I have found an archive of the Cryptography Digest at the web
site "The Mail Archive", but they only go back to August of
this year.
Surely there must be archives somewhere that are earlier than this ?
Surely such a quality educational list as this one has not been kept
from it's beginning for future generations ?
If someone knows of such an archive site, that hopefully, goes
right back to the beginning of the list, or if some individual has them on
their computer, I would love to know !
Even if some kind soul can email them to me ?
Pls help, I'm desperate !
Cheers!
Mark Harrop
[EMAIL PROTECTED]<mailto:>
Moderator of the following Programming Lists:
Send a empty message to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Cheers!
Mark Harrop
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Moderator of the following Programming Lists:
Send a empty message to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
+<(:o)|<:
--=====================_15684435==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Hi all...<br>
<br>
I have found an archive of the Cryptography Digest at the web<br>
site "The Mail Archive", but they only go back to August
of<br>
this year.<br>
<br>
Surely there must be archives somewhere that are earlier than this
?<br>
<br>
Surely such a quality educational list as this one has not been kept
<br>
from it's beginning for future generations ?<br>
<br>
If someone knows of such an archive site, that hopefully, goes<br>
right back to the beginning of the list, or if some individual has them
on<br>
their computer, I would love to know !<br>
<br>
Even if some kind soul can email them to me ?<br>
<br>
Pls help, I'm desperate !<br>
<br>
<x-sigsep><p></x-sigsep>
Cheers!<br>
Mark Harrop<br>
<b>[EMAIL PROTECTED]<a href="mailto:"><br>
<br>
</a>Moderator of the following Programming Lists:<br>
<br>
Send a empty message to:<br>
<br>
[EMAIL PROTECTED]<br>
<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
</b><br>
<font face="Comic Sans MS" color="#000080"><br>
</font>Cheers!<br>
Mark Harrop<br>
<b>[EMAIL PROTECTED]<br>
[EMAIL PROTECTED] <br>
[EMAIL PROTECTED]<br>
<br>
<br>
Moderator of the following Programming Lists:<br>
<br>
Send a empty message to:<br>
<br>
[EMAIL PROTECTED]<br>
<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
<br>
+<(:o)|<:</b></html>
--=====================_15684435==_.ALT--
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 24 Nov 2000 09:53:14 +0100
[EMAIL PROTECTED] (David Wagner) wrote:
> I seem to have misplaced the source, but an example of the results may
> be found at <http://www.cs.berkeley.edu/~daw/my-posts/crypt-collision>.
>
> However, it was very easy to implement. Basically, you pick a set of
> distinguished points (e.g., the 64-bit blocks whose low 20 bits are all
> zero), then you iterate f() at high speed until you hit a distinguished
> point. When you see a dist. pt., you enter it into some central table,
> and then continue iterating. When you encounter the same dist. pt.
> twice, then you've found a collision in f(), which is exactly what you
> wanted to find. By storing the iteration count along with each
> distinguished point in the central table, once you see a collision you
> can backtrack to find the two pre-images that map to the same output.
Thanks for the reference, and clear explanation. This is indeed
an effective solution to the parallel collision search problem.
The cycling algorithm I describe in my other post this morning is not
easy to distribute (but efficient enough that it does not need to be
in the case of DES). Yours is roughly as efficient, in fact nearly as
efficient as search with instant access to unlimited RAM.
Do you know if, appart from applying the technique to other
problems, there is another refinement in
Paul C. van Oorschot and Michael J. Wiener.
Parallel collision search with cryptanalytic applications.
Journal of Cryptology, 12(1):1-28, 1999.
<http://link.springer.de/link/service/journals/00145/bibs/12n1p1.html>
which looks like a must-read anyway ?
Francois Grieu
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Fri, 24 Nov 2000 09:11:12 +0100
Matt Timmermans wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote:
> > So entropy in my view IS, as you said, indeed somewhat
> > subjective, though I am afraid there are some who would
> > object.
>
> Well, there are lots who would object if I said that physical entropy, i.e.,
> entropy as in physics, is subjective, but I wouldn't say that here.
>
> As long as we understand that we're talking about entropy as practical
> uncertainty, I believe that all of your respondents so far would agree.
>
> > Now let's assume that there is an appropriate measure
> > of that. As you claimed, that entropy can be amplified. But
> > what 'enables' that amplification? Some energy or what?
> > Thanks.
>
> One-way functions enable that amplification. I don't think that I can
> visualize "one-wayness" as any sort of quantity or substance.
But that's the problem. In probability theory there is also
the subjective probability, which could be considered
quite related to the 'subjective' entropy, I suppose. Now
the subjective quantity, while not objective, must still
behave fairly similary. In our case we have something like
some entropy + code of a function = more entropy
However, the code, according to the common assumptions in
crypto, is known to the opponent and hence must have
zero entropy. That would however render the above relation
absurd.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Fri, 24 Nov 2000 09:11:31 +0100
Scott Craver wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >This is a re-formulation of an issue that I questioned
> >previously. Suppose one has m perfectly random bits and
> >uses that in some appropriate way to get a BBS generator
> >to generate u bits, with u >> m.
>
> There are only 2^m possible values for u.
> Each of these strings has probability 1/2^m
> (assuming the bits of m are uniform and the BBS
> function is 1-to-1), and all other values have
> probability zero, so the Shannon entropy is m
> bits.
>
> Notice, BTW, that the definition of Shannon
> entropy does not depend on the actual values
> a random variable takes on, but merely their
> probabilities. So if f() is a function that
> is 1-to-1, H(X) == H(f(X)). I.e., the "names"
> of the variable's outcomes don't matter.
>
> >the u bits are provably secure.
>
> How is a string of bits provably secure?
> I suppose you mean that, given the first
> u-1 bits, the next bit can not be predicted
> any better than randomly, in compute time
> that "reasonable."
Well, as discussed some time ago, BBS depends on the validity
of some assumptions and the security is certainly not the
same as the theoretical OTP. (Provable security is in fact
often a loose terminology.)
> >that way, i.e. having obtained an amount of additional
> >entropy from nothing. How is this apparent paradox to be
> >properly explained?
>
> As above, the entropy is still m. Amusingly,
> if you are given the first (u-m) bits, the
> entropy of the remaining m bits is ... ?
> Zero. Because given the first (u-m) bits,
> chances are you have completely determined
> the BBS generator seed. Just try all 2^m seeds
> until you have the one with those (u-m) bits.
As mentioned elsewhere, the 'problem' is a practical one.
Suppose we can't brute force the BBS (given a large m and
a good construction, this is certainly achievable), then
the output of it is as good as a perfectly random one (if
such can be known to exist) for our purpose and can hence
be accorded full entropy ('subjective' entropy in the term
of Matt Timmermans). Now if the first m bits of u bits has
m' bits of entropy, the second m bits must also have
approximately that (there is no reason to claim otherwise).
Following this reasoning, one would then get into a
paradoxical situation.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Fri, 24 Nov 2000 09:27:32 +0100
Bill Unruh wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
> ]I suppose that BBS and its assumptions and proof are known.
>
> Not to me it is not.
>
> ]I assume that you do the best so that all the entropy in
> ]the given m bits are incorporated into the generator. In
> ]other words, BBS is viewed as a black box with m bits as
> ]input and u bits as output. Is this concept clear? Or do
> ]you contend the correctness of the assumptions and/or
> ]the proof of BBS? Thanks.
>
> Yes, I claim that the proof that this generator is "provably secure"
> whatever that means, is either wrong or you are misinterpreting it.
> Is BBS supposed to be some real existing system,a nd th proof some real
> proof that I can now go and read somewhere? Where?
BBS is dealt with a bit in Schneier's AC, from which
you could get further pointers. There was also some
past discussions on BBS in the group.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Fri, 24 Nov 2000 09:18:42 +0100
John Savard wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>
> >If the u bits are very secure, what would the same number
> >u of perfectly random bits (we suppose that these are
> >obtainable) distinguish themselves from these? They
> >are totally equivalent for the practice, aren't they?
>
> Only if a brute-force search over the 2^m possibilities for the m bits
> they came from is absolutely impossible.
>
> They're equivalent *for some purposes*.
>
> But while, when m is large enough, you can't work backwards from the u
> bits to the m bits in practice, you can always work forwards from the
> m bits to the u bits in practice. That's the distinction between the u
> bits from the BBS generator, and u perfectly random bits.
>
> So there is no distinction in cryptosecurity, but there IS a
> distinction in entropy. Hence, no paradox.
As I mentioned, we consider a bit that nobody on earch
can predict to have full entropy. So it is a practical
issue.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Fri, 24 Nov 2000 09:20:51 +0100
Bill Unruh wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
> >So if BBS generates u bits and I take m bits out of it,
> >how much entropy is in there? Thanks.
>
> Who knows. Zero? m? ...?
> It depends entirely on what BBS is.
We assume a well-constructed BBS.
M. K. Shen
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: RSA Signature !
Date: Fri, 24 Nov 2000 10:22:07 +0100
Frederic Donnat <[EMAIL PROTECTED]> wrote:
> I'd need to make my own Signature with RSA.
Don't ! Use a standard padding technique, such as
ISO/IEC 9796-2. To find a current working draft,
which describes the standard in section 8, use
<http://www.google.com>
with keywords: 9796-2 PDF [I looove google !]
Francois Grieu
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Date: Fri, 24 Nov 2000 09:34:18 GMT
: Why would that be surprising ? [...]
> Because these books are copyright material, and (AKAIK) not available
> free of charge over the internet.
Errr, what you find on the Internet is not based on copyright or
legal rights, but on its real interest : best books and softwares
are available for free faster than bad ones, at least on the part
of Internet I use.
> Note that no one has managed to post URLs for the texts of any
> of the books in Richard's list.
Why exactly would someone want to post URLs to illegal material
on a public newsgroup ? To get the server closed ?
> What reason is there to think that searching for them would
> not be a complete waste of time?
Of course my post is in no way a proof. However, since Paul Rubin
confirmed that AC2 is available in electronic format on a CD-ROM,
thinking that it cannot also be available somewhere on the Internet
is IMO pretty naive.
Now feel free to ignore what I said (or to "maintain your position" :)),
because I will spend no more effort in this thread to prove anything.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 24 Nov 2000 09:47:40 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Man arrested in stolen Enigma case
Francois Grieu wrote:
>
> Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > Francois Grieu wrote:
> > > source: <http://www.bletchleypark.org.uk/press.htm>
> >
> > Old news. Did you not see the article I posted on Saturday
> > afternoon, under the heading "Enigma Development"?
>
> Sorry, missed your post (now I got it). Still my source is new.
> And repetition is the essence of Usenet.
Repetition is the essence of Usenet.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
** 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
******************************
