Cryptography-Digest Digest #852, Volume #13 Sat, 10 Mar 01 06:13:00 EST
Contents:
Re: Text of Applied Cryptography (Joe H. Acker)
Re: One-time Pad really unbreakable? (Dave Knapp)
Re: boycott Russia.... ("WW")
Re: Text of Applied Cryptography (Joe H. Acker)
Re: Q: Help needed -- reverse-engineering stream-encoderésequence generator ("Vlad
ROMASCANU")
Re: One-time Pad really unbreakable? (Mok-Kong Shen)
Re: Super strong crypto (Mok-Kong Shen)
Re: Super strong crypto (Mok-Kong Shen)
Re: Text of Applied Cryptography (Paul Rubin)
Re: Encryption software ("Henrick Hellström")
Re: The Foolish Dozen or so in This News Group (Benjamin Goldberg)
Re: => FBI easily cracks encryption ...? (Mok-Kong Shen)
Re: The Foolish Dozen or so in This News Group (Benjamin Goldberg)
Re: Text of Applied Cryptography (Benjamin Goldberg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography
Date: Sat, 10 Mar 2001 09:14:21 +0100
Ryan M. McConahy <[EMAIL PROTECTED]> wrote:
> I am _not_ a troll! If I can't find it from you, I'll find it somewhere
> else.
How about going to a public library?
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Sat, 10 Mar 2001 08:17:00 GMT
On Fri, 9 Mar 2001 10:59:32 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>
>: In contrast, the irreducible nature of quantum randomness has been well
>: established by experiment and theory. It's not due merely a lack of
>: more detailed knowledge of the state of the system.
>
>Yet there are deterministic theories of how the world operates, which
>appear to be quite consistent with observation:
>
>http://www.anthropic-principle.com/preprints/manyworlds.html
>
>Q13 Is many-worlds a deterministic theory?
> Yes, many-worlds is a deterministic theory [...]
>
>A deterministic theory has no place for randomness.
Wrong. Thanks for playing, though. The many-worlds hypothesis (it
isn't a theory yet) is deterministic, but it is unable to predict the
results of a single observation, since the worldline in which the
observation will be made is unpredictable. Thus, the inherent
randomness of quantum mechanics has just been pushed one layer back.
-- Dave
------------------------------
Reply-To: "WW" <[EMAIL PROTECTED]>
From: "WW" <[EMAIL PROTECTED]>
Crossposted-To: comp.security,alt.security,alt.2600
Subject: Re: boycott Russia....
Date: Sat, 10 Mar 2001 02:38:39 -0600
They also make pilotless MIR bombs..............
René <[EMAIL PROTECTED]> wrote in message
news:u4lq6.6209$[EMAIL PROTECTED]...
> _What_ Russian products? Do they actually _make_ something? Other than
that,
> that's fine with me. Not that I care too much for these pestering
Witnesses,
> but I can tolerate them. Russians on the other hand..I fucking hate
> them...come to think it, yes, Russia makes the famous AK's....which
suck...
>
>
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography
Date: Sat, 10 Mar 2001 09:41:37 +0100
<[EMAIL PROTECTED]> wrote:
> On Fri, 9 Mar 2001 17:31:37 -0500, "Ryan M. McConahy"
> <[EMAIL PROTECTED]> wrote:
>
> >I am _not_ a troll! If I can't find it from you, I'll find it somewhere
> >else.
>
> Enjoy. Might not be the newest but it is all out there.
> Courtesy of the authors.
>
> Handbook of Applied Cryptography
> http://www.cacr.math.uwaterloo.ca/hac
> Applied Cryptography: Schneier
> http://134.155.63.117/quantico/TE/appliedcrypto.zip
That last link is essentially useless because you will need the original
text to compare it with this .html version. The page
http://134.155.63.117/quantico/TE/ also contains binaries, even of PGP
6.5.8 private version. Anyone who intends to run such a binary on his
machine submits himself to the motto that is stated as a subheading on
that page: "No risk - no fun. No questions - no lies. Have a nice day."
The most important factor in cryptography is trust, and I give this page
a trust of 0 (in letters: zero).
Regards,
Erich
------------------------------
From: "Vlad ROMASCANU" <[EMAIL PROTECTED]>
Subject: Re: Q: Help needed -- reverse-engineering stream-encoderésequence generator
Date: Sat, 10 Mar 2001 04:11:53 -0500
Hello,
> To make further progress I'd suggest some non-periodic tickling
> experiments; e.g. compare 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
> with 00 00 00 00 01 00 00 00 00 00 00 00 00 ... and similarly for
> other single-bit positions in the input stream. (Impulse functions.)
Yes, that's exactly what I ended up doing and, sure enough, it led me to the
solution. :)
> The data you presented seems to have started at some "reset" state;
> after a reset, do you *always* get the same outputs when you provide
> the same input sequence?
Yes, I reset the encoder before each sequence, and it is consistent (the
same input stream will always produce the same corresponding output stream).
> An interesting puzzle..
Quite so. :) It is used by SoundBlasters, through an undocumented command
(DSP command 0xe2). Quite a convoluted way for a piece of hardware to
identify itself. ;)
BTW, the solution I came to is in another article in this thread that I
posted a little while earlier.
Thanks,
Vlad.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Sat, 10 Mar 2001 10:39:26 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > "Douglas A. Gwyn" wrote:
> > > Determinism can still involve random processes.
> > Could you please elaborate your first sentence?
> Not without a long discourse on the meaning of determinism
> in the philosophy of science. Determinism, causality, and
> nonrandomness are similar but technically all different.
It's not that philosophical but concrete. Random processes
entail events that cannot be exactly predicted/calculated.
If these are discernible within the capability of
measuring instruments, then they cause results of
observations that fluctuate and nondeterministic, unless
one declares these to be unessential and take average
values. In material sciences, for example, the stress
strain relation determined from different specimens
of steel are not identical, but one takes the average of
experimental results and defines/considers that to be
the unique relationship that exists and thus overlooks the
presence of 'randomness' for practical purposes.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 10 Mar 2001 10:39:30 +0100
"Douglas A. Gwyn" wrote:
>
> Let me put it this way: You don't need guardrails on mountain
> roads if nothing will go wrong, but highway engineers generally
> add them as a safety precaution *against a foreseeable class of
> contingencies*, even though it costs something to do so.
Is this responding to my previous follow-up? Note that
in an earlier response, you said that a scheme mentioned
by me needed more bandwidth than yours. Isn't that
contradictory to the above? (Couldn't add even some more
costs -- more bandwidth?) Note, however, that, as said in
my previous follow-up, that scheme is flexible and can be
adjusted to achieve the 'same' bandwidth as yours and,
since it avoids the domino effect, should be better than
your so-called super system.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 10 Mar 2001 10:39:39 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > Could you please clearly point out ...
>
> I recently commented on (2) and refer you to that.
> Otherwise, I'm going to resist the bait. I don't
> care whether your alternative schemes are better
> or worse, just that you're giving these issues more
> consideration than has traditionally been done.
See what I wrote in a parallel follow-up posted simultaneously.
It applies anyway also to the above, even if that other
follow-up turns out to be in the wrong place.
M. K. Shen
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography
Date: 10 Mar 2001 01:56:30 -0800
[EMAIL PROTECTED] writes:
> Enjoy. Might not be the newest but it is all out there.
> Courtesy of the authors.
>
> Handbook of Applied Cryptography
> http://www.cacr.math.uwaterloo.ca/hac
> Applied Cryptography: Schneier
> http://134.155.63.117/quantico/TE/appliedcrypto.zip
I know about HAC but I had never heard that Bruce Schneier released
Applied Cryptography like that. If it's true it's great. Otherwise
it's not very nice of whoever uploaded it.
I've downloaded the file and it appears genuine. It also looks like
the real thing. It appears to have been on Earthweb.com for a while
but I don't know about now. It's not some hack job of scanning the
book or converting the DDJ .pdf file--someone did a lot of work making
the HTML file, which gives me the impression it was legitimately done,
though maybe it was supposed to only be available to Earthweb paying
customers or something like that.
Anyway, if Bruce is reading this I hope he'll comment.
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Encryption software
Date: Sat, 10 Mar 2001 11:03:19 +0100
Yes, but you can't generate it with MS Outlook or OE. If you don't have a
key, you are instructed to purchase one from VeriSign.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Paul Rubin" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> "Henrick Hellström" <[EMAIL PROTECTED]> writes:
> > I agree. In particular, I don't think it is worth the money to pay
someone
> > else to generate your own private key (or whatever they do in order to
give
> > you a "certificate"). It seems like a somewhat strange idea, in
particular
> > when you know a little about MS's track record in the field of computer
> > security.
>
> A certificate in the x509 world is just like in PGP--it just means
> somebody signs your public key. You generate your own key pair.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 10:07:26 GMT
Anthony Stephen Szopa wrote:
>
> Benjamin Goldberg wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> > > Troed wrote:
> > > >
> > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >This is a personal use program for windows. I think it is fair
> > > > >to say this program is for and intended for a non multitasking
> > > > >environment.
> > > >
> > > > It's for Windows 3.x only? Windows 95 and up are pre-emptive
> > > > multitasking - or what are you talking about?
> > > >
> > > > >Take a look at my floppy disk test results I just posted. They
> > > > >seem to cramp everything pretty much all the detractors have
> > > > >been saying.
> > > >
> > > > Floppy != Harddrive
> > > >
> > > > ___/
> > > > _/ - Software Engineer working in the development of
> > > > operating systems
> > >
> > > You should not have other programs running at the same time as you
> > > are running the OverWrite program that will be making demands on
> > > the system such that the overwrites to the hard drive will be
> > > delayed by competition from these other programs for system
> > > resources. You don't want to be running multiple tasks or
> > > programs while the OverWrite program is running if at all
> > > possible.
> >
> > If your algorithm is designed properly, that should not make a
> > difference.
>
> Catch 22!!!
>
> You've been all telling me that there is no way to design the
> program properly to make sure 100% of the time that the physical
> overwrites are taking place because of optimizations built in to the
> Windows OS.
Well, no way to do it with platform independent stuff like the stdio
library.
> Now you are telling me that it can be done. Are you taking both
> sides?
Heh. Yes and no. If you algorithm is designed properly, it will work
regardless of whether other things are running, but if your algorithm
uses platform independent code, there is no way at all for it to
provably, consistently, work.
I suppose that to you, with your limited knowledge and abilities, this
might appear to be a catch 22. The trick to designing the algorithm
properly is that you have to write code which is targeted for your
specific platform: probably this will have OS specific calls, and it
might possibly even need to be added to the kernel, to the OS itself, to
work.
> I have attempted to make the overwrites take place by allowing
> enough time between subsequent calls to the write and fclose
> functions in each pass so that the OS will make these overwrites.
A good idea, but how much is "enough time?" Also, is your clock
measuring what the computer refers to as "user time," or "system time?"
Or are you trying to do something which measures wall clock ("real")
time?
If you can learn from Microsoft exactly how long it takes for the OS
timer to automatically write the OS write-behind buffers to disk, and
what it is on ALL the various dos/win platforms you are willing to
support your software for, and have the program figure out which
platform it's running on, then you can realistically say that it will
assuredly work, without fear of contradiction.
However, if you just say "enough time" without learning what it is for
real, or without siting the source for this info, then you're going to
get people disagreeing with you, or at least saying, "How do you know
that for sure?" and/or "Prove it!"
Note that I, personally, do not believe that using the OS timer for
buffer flushing is the best way of doing things. The best way, IMHO, is
to find a windows-specific library function which directly interacts
with windows's write-behind functionality. (1) Your software should
read from the OS whether write-behind is turned on, then your program
should turn it off, and, after doing the writes, your program should
restore write-behind to it's original setting. (2) Your software
should, after each fclose, send commands to the hdd which causes the hdd
to physically write its buffers. There are OS->hdd commands to do this,
as they are sent from the OS to the hdd during shutdown.
A third, best, possibly only trustable way, is the following:
1) locks the file so that no other program can have it open
2) access OS internals to learn what file system is in use
3) access OS internals to learn what hdd sectors the file resides on
4) access device driver internals or OS internals to push blocks of data
(random whitening, or whatever it is your replacing the data with)
directly to the hard drive, bypassing the OS io operations.
5) access device driver internals or OS internals to command the hdd to
physically write the blocks of data it has in memory to the disk.
6) repeat 4 and 5 as necessary.
Great care should be taken when writing disk sectors directly to not
mess up file system info (like pointers to next/prior blocks, whatever).
> The overwrites should physically take place as long as there are not
> other competing physical writes such that any subsequent write and
> fclose instructions are processed before the prior overwrite has
> had a chance to physically take place.
It's not that physically writing takes a while. It's that once you
finish sending data to the OS, it sits around in the OS buffers...
The only things which cause the OS buffers to get sent to disk, is
enough writes so that the buffer cache gets full, or a special clock
going off, indicating, "this has sat around for a while without being
accessed, there's probably no performance gain to keeping it around in
memory, it would be a good idea to write it to disk"
Remember, fclose only flushes C library buffers (stdio buffers), and
doesn't do anything about OS buffers.
Also, you have to find sources of information on hard drive buffers. I
have no clue as to how long the hdd keep stuff around -- I've heard OS's
keep buffers around for as long as 30 seconds, but I've never read any
info on how long various hdds keep data in their buffers. Is it flushed
by timer, or only when the hdd buffers are full? I don't know. You
have to find this out for people to be able to trust your software. Or
else you have to find a way to send commands directly to the hdd,
telling it to flush its own buffers.
> I believe this was the issue.
>
> This is why I recommend that other programs not be running.
Hmm. Unless those other programs are accessing the data you're
overwriting, then it still shouldn't make much of a difference. At
least, not with the simplistic approach you're taking.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sat, 10 Mar 2001 11:09:43 +0100
Paul Rubin wrote:
>
> [EMAIL PROTECTED] (Damian Kneale) writes:
> > Not at all, and do you think that the NSA are about to admit that they
> > can listen in to (as a random example) Japanese Diplomatic codes, but
> > not naval codes? Or that France has better encryption and key
> > generation than Spain?
>
> Again, you're pretending the present situation is comparable to
> WW1/WW2 and things aren't like that now. For example, the new edition
> of Kahn's "The Codebreakers" has a chapter at the end, which claims
> that the battle between cryptographers and cryptanalysts (that the
> book chronicles) is now over--because of computers, the cryptographers
> have won.
An analogy would be between evolution of virus and
development of medicaments. The virus play in a sense the
active part because it can mutate in ways and at timepoints
unknown and thus have the advantage in that the medicaments
have to follow its direction, not vice versa. But it
couldn't be excluded that at a certain time point one party
succeeds to make a major jump, till later the other party
does the same and the game continues on. One never knows for
sure what knowledge of cryptanalysis the secret agencies
currently have, only what the academics have. Thus I think
one should have some reservation about what Kahn concludes.
M. K. Shen
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 10:36:59 GMT
Anthony Stephen Szopa wrote:
>
> Benjamin Goldberg wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> > > Scott Fluhrer wrote:
> > > >
> > > > It is written "Argue not with a fool, lest you be like him".
> > > > Here I go again ignoring that excellent advise...
> > > >
> > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> > > > news:[EMAIL PROTECTED]...
> > > > > Scott Fluhrer wrote:
> > > > > >
> > > > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> > > > > > <SNIP BIGTIME>
> >
> >
> > --
> > The difference between theory and practice is that in theory, theory
> > and practice are identical, but in practice, they are not.
>
> You've taken your first quote out of context. I has meaning when you
> include the two immediately following sentences.
*I*'m taking stuff out of context? You're the one doing megasnips.
> "A file can be written to one place on a hard drive then read into
> cache. Processed then written to a completely different place on
> the hard drive. And this process can continue I suppose until the
> entire hard drive has been written over once and no bit locations
> have been overwritten."
This is entirely 100% true. In fact, in a transaction based system,
this is quite close to what actually happens.
> File is opened in "r+b" mode.
That has little to do with anything.
> A block is loaded into cache not a sector. Block sizes vary.
Block sizes are file system artifacts, sectors are disk artifacts.
> I believe that there are plenty of statistics available that prove
> the accuracy, reliability and predictability of computer technology.
> And most bad sectors have been previously identified and are
> routinely avoided where they will not cause runtime errors in write
> / read operations.
Regardless, they *can* happen. You, the defender, assume they won't
ever. I, the attacker, assume they will, at least some of the time.
> I don't believe that the entire block (not sector) from cache is
> rewritten back to the hard drive. This would be inefficient. I am
> quite sure that at most only the updated file is rewritten to the
> hard drive. But a good point of focus.
This is your belief. Do you have evidence one way or another?
> Most likely when the overwrite program is the only program running
> and the only program accessing the hard drive that the drive heads
> will remain where they last read / wrote from / to the hard drive.
Where the drive heads are is much less important than what's in the
hdd's onboard cache.
> As well, there are most likely other blocks on both sides of the
> block / file to be rewritten to the hard drive and this location
> will be closest and I would think most likely that the rewrite will
> most likely take place at the original file location.
Not sure what you're saying, and not sure I agree with you if it is what
I think you might be saying.
> The OS and hardware cannot ignore a coded instruction indefinitely.
It never ignores instructions. Later instructions can cancel earlier
ones. Where you get off calling buffering "ignoring" instructions I
don't know.
> This is the reasoning behind my updating the OverWrite program. If
> the OS and hardware is given enough time it will carry out the write
> operation.
>
> Are you arguing otherwise?
It's not the time it takes for the operation to take place. OS Buffers
stick around until something forces them out (things going into new
buffers, or a timer, or shutdown). How long things stay in hdd buffers
I don't know, but I 'spect it's the same.
> Compressed files: This was another point raised. Wouldn't you agree
> that the user is intending to overwrite the file as it exists. How
> it got to be the file it is is not the concern of the OverWrite
> program. This may be a concern of the user.
I'm not talking about "compressed files" I'm talking about the hdd or
the OS compressing things for you. Some of these do, ya know.
Suppose you have a file which, originally, is 10kb of the ascii letter
"a" repeated many many times. Further, suppose your hard drive does
automatic compression. To the user, or even to the OS, this will LOOK
like the letter "a" repeated x times. The hdd, however, has compressed
it down to one sector. Now you want to write 10kb of random data in its
place (since you see it as a 10kb file). The hdd says, ack, I've been
pretending this one sector is x 100 blocks, but now someone's trying to
write x 100 REAL sectors of data there... I guess I have to write it to
x 100 actual sectors. Now where can I find x 100 contiguous sectors...
here we go (and add old, one sector, to list of free sectors). Get the
idea?
> "I think that by now, everyone [except Szopa] is able to see that his
> algorithm is not guaranteed to properly overwrite an arbitrary file."
>
> I guess I struck a cord for you to jump to such a conclusion in light
> of my just made point, no?
No, I had made that conclusion a while ago, after you had repeatedly
said many many stupid things.
> I do not believe that debate is about winning at all costs. I believe
> it is about getting to the truth of an issue.
Yes, absolutely right.
> When a person lies or tries to deceive then the debate has
> gone off topic but not necessarily void of enlightenment.
You attempt to decieve us into beliving that your algorithm is
wonderful, fantastic. We attempt to present the facts, and thus
enlighten you. I have learned from some of the other people things
which I hadn't known, and thus am enlightened. What have you learned
from our responses to your lies?
> Defragmented disks: again, OverWrite is not responsible for multiple
> file copies. It is only tasked with overwriting the file you tell it
> to.
Ok, I accept this response. It's a decent excuse for not handling the
problem.
> Transactioning: Same as above. What you might want to do is write a
> file large enough to cover your entire hard drive then use OverWrite
> to overwrite your entire damned hard drive ;-)
This is... half decent. You should have your program attempt to
determine what file system is actually in use, and DETECT if it's a
transactional system, and EXIT with an error message, if it is.
> Raid disks: if you have multiple copies of a file that you want to
> overwrite then you must tell the OverWrite program to overwrite each
> and every one of them.
Clearly, you do not understand what RAID disks are. Go reread whatever
you can find on them, and then come back and answer.
> It sounds like what you are proposing is that I upgrade the OverWrite
> program to also scan your entire hard drive byte by byte for any
> partial strings that are sub strings of the file you are intending to
> overwrite as well and over write these as well. Good idea. I'll
> keep it in mind.
That would be one (bad) way to deal with the defrag issue. However, a
better way would be to compile a list of all free hdd sectors, and then
write over them with random data. Of course, your would probably have
to make this functionality part of your disk defragmentor itself, since
it is handling free blocks... if you try it some other way, things can
get messy.
> But for now, the OverWrite program is a simple overwrite utility.
> Tell it to overwrite one file and I believe it does it and I have
> told you why.
You are free to believe what you want. Just don't expect us to agree
with your beliefs.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography
Date: Sat, 10 Mar 2001 10:52:08 GMT
Paul Rubin wrote:
>
> [EMAIL PROTECTED] writes:
> > Enjoy. Might not be the newest but it is all out there.
> > Courtesy of the authors.
> >
> > Handbook of Applied Cryptography
> > http://www.cacr.math.uwaterloo.ca/hac
> > Applied Cryptography: Schneier
> > http://134.155.63.117/quantico/TE/appliedcrypto.zip
>
> I know about HAC but I had never heard that Bruce Schneier released
> Applied Cryptography like that. If it's true it's great. Otherwise
> it's not very nice of whoever uploaded it.
>
> I've downloaded the file and it appears genuine. It also looks like
> the real thing. It appears to have been on Earthweb.com for a while
> but I don't know about now. It's not some hack job of scanning the
> book or converting the DDJ .pdf file--someone did a lot of work making
> the HTML file, which gives me the impression it was legitimately done,
> though maybe it was supposed to only be available to Earthweb paying
> customers or something like that.
>
> Anyway, if Bruce is reading this I hope he'll comment.
It's most likely an illegally made available copy. If it were
legitimate, it would be on the same website as HAC, probably with a url
like http://www.cacr.math.uwaterloo.ca/ac. However, since that site
talks about selling the pdfs for AC, not giving them away, it's a pretty
sure bet that the 134.155.63.117 version is illegal. Not that it
mightn't've been legally purchased, but I doubt that posting it for
anyone to see is/was legal.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
