Cryptography-Digest Digest #478, Volume #14 Wed, 30 May 01 19:13:01 EDT
Contents:
Question about credit card number (Chenghuai Lu)
Re: Question about credit card number (John Joseph Trammell)
Re: Medical data confidentiality on network comms ("Roger Schlafly")
Re: Cool Cryptography Website! (John Savard)
Re: Good crypto or just good enough? ("Joseph Ashwood")
Re: Good crypto or just good enough? (David Wagner)
Re: Good crypto or just good enough? ("Roger Schlafly")
Re: "computationally impossible" and cryptographic hashs ("Dj Le Dave")
Re: Good crypto or just good enough? (David Wagner)
Re: "computationally impossible" and cryptographic hashs ("Dj Le Dave")
differential oddity (Tom St Denis)
Re: National Security Nightmare? (Sam Yorko)
Re: Medical data confidentiality on network comms ((chenshaw@(T<H+ESE)sympatico.ca)
(Coridon Henshaw))
Re: National Security Nightmare? (Tom St Denis)
question: how does brute force key search work? ("Peter Schurman")
Re: question: how does brute force key search work? (Tom St Denis)
Re: National Security Nightmare? (Sam Yorko)
Re: Medical data confidentiality on network comms ("Jordan C. Wiseman")
Re: National Security Nightmare? (Tom St Denis)
Re: Good crypto or just good enough? ("Joseph Ashwood")
PGP Weakness??? ("Dave Rudolf")
Re: National Security Nightmare? (SCOTT19U.ZIP_GUY)
Re: National Security Nightmare? (JPeschel)
Re: Cool Cryptography Website! ("Mark Lomas")
----------------------------------------------------------------------------
From: Chenghuai Lu <[EMAIL PROTECTED]>
Subject: Question about credit card number
Date: Wed, 30 May 2001 16:06:18 -0400
I have some questions below.
Most of the commecial websites keep the customers' credit card numbers
in their database.
Does anyone know how they store the credit card numbers in their
database?
Are they stored in encrypted form, or just in plaintext?
There are some websites being hacked, and the credit card numbers are
stolen by hackers.
How can the hackers get the credit card numbers if they are encrypted?
Thanks.
Lu
--
-Chenghuai Lu ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (John Joseph Trammell)
Subject: Re: Question about credit card number
Date: Wed, 30 May 2001 20:25:19 GMT
On Wed, 30 May 2001 16:06:18 -0400, Chenghuai Lu <[EMAIL PROTECTED]> wrote:
> I have some questions below.
>
> Most of the commecial websites keep the customers' credit card numbers
> in their database.
>
> Does anyone know how they store the credit card numbers in their
> database?
> Are they stored in encrypted form, or just in plaintext?
>
> There are some websites being hacked, and the credit card numbers are
> stolen by hackers.
>
> How can the hackers get the credit card numbers if they are encrypted?
In my experience, commercial websites only use some sort of obfuscation
(e.g. ROT18) on the credit card numbers.
I believe they are prohibited by the credit card company from storing
the CC # in plaintext form.
Even *if* some form of real encryption is used, it's usually moot
because the key is left lying around in programs used to access the
data; access to the database is likely to yield both the encrypted
data and the key.
--
and how does it feel like/to let forever be
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Wed, 30 May 2001 19:28:47 GMT
"Larry Kilgallen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <P37R6.79$[EMAIL PROTECTED]>, "Roger Schlafly"
<[EMAIL PROTECTED]> writes:
> > Once a medico has computer access to a digital record, it is very
> > difficult to keep him from making unrestricted copies.
> It depends on what you mean by "very difficult". If they want it
> on computer media, they would have to attach a drive to the workstation
> they use to access the data. The would also have to break into the
> application that presents the results to them on that workstation.
> Of course if an organization tries to take stock Microsoft machines
> and uses file transfer to deliver results to them, all bets are off,
> but organizations that take no precautions in this regard are not
> worth discussing.
Do you know of an organization that keeps all its medical (or similar)
data on a cryptographically secure network, and the only possible
read access is on a screen or some other medium that is not easily
copied? If so, I am pleasantly surprised.
Do it handle data coming in and out of the organization in a secure
manner? Tell me more. The average US hospital is probably 20
years away from doing anything like that.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cool Cryptography Website!
Date: Wed, 30 May 2001 20:27:39 GMT
On 30 May 2001 18:20:57 GMT, [EMAIL PROTECTED] (JPeschel)
wrote, in part:
>If it's any solace, John --most of the regulars here know
>that you are the original author of the work, and that you have
>copyrighted it.
I realize that, and yes, it is solace. Thank you.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Wed, 30 May 2001 11:43:28 -0700
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:2yBQ6.10941$lm5.1577845@news6-
> Assuming unrelated keys, what is the proof that 3DES is stronger than DES?
Proving that 3DES is at least as secure is performed easily by relating the
keys, in particular by setting all keys to the same value and assuming EDE
(which is the norm, and the specification). From there you have exactly DES,
so 3DES can be no weaker than DES. Proving that 3DES is strictly stronger
than DES is difficult at best, what we can prove is that it resists the
attacks we know of better than DES, that is generally sufficient to
establish that it is most likely stronger.
Joe
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Good crypto or just good enough?
Date: Wed, 30 May 2001 20:36:16 +0000 (UTC)
Joseph Ashwood wrote:
>Proving that 3DES is at least as secure is performed easily by relating the
>keys, in particular by setting all keys to the same value and assuming EDE
>(which is the norm, and the specification).
This is not allowed---you have changed the problem.
It is implicit in the description of most encryption algorithms
that keys are generated uniformly at random from the keyspace;
for 2-key 3DES, this is a 112-bit keyspace, and for 3-key 3DES,
this is a 168-bit keyspace.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Wed, 30 May 2001 19:41:44 GMT
"David Wagner" <[EMAIL PROTECTED]> wrote
> Joseph Ashwood wrote:
> >Proving that 3DES is at least as secure is performed easily by relating
the
> >keys, in particular by setting all keys to the same value and assuming
EDE
> >(which is the norm, and the specification).
> This is not allowed---you have changed the problem.
> It is implicit in the description of most encryption algorithms
> that keys are generated uniformly at random from the keyspace;
> for 2-key 3DES, this is a 112-bit keyspace, and for 3-key 3DES,
> this is a 168-bit keyspace.
In which case it is theoretically possible that 3-key 3DES is less
secure than 2-key 3DES.
------------------------------
From: "Dj Le Dave" <[EMAIL PROTECTED]>
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Wed, 30 May 2001 21:03:34 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9f1m3u$dr1$[EMAIL PROTECTED]...
>
> Dj Le Dave <[EMAIL PROTECTED]> wrote in message
> news:yJYQ6.7617$[EMAIL PROTECTED]...
> > Related to this, I always wondered why UNIX (and other such systems)
> bother
> > to hash at all. Could they not just "encrypt" the entire password, so to
> > speak? Break it up into 56-bit blocks (or whatever) and perform the hash
> > independantly on each block, then concat. all the output together to
form
> > the password file entry. This way, an attacker would have to essentially
> > have to do a plaintext-cyhertext attack on each block to get the whole
> > password. Thus, if the password is X bits long, then the attacker would
> have
> > to brute-force all X bits (well, except for dictionary attacks, etc.).
> And,
> > we don't run into the birthday-paradox, as DES is a one-to-one function.
> At
> > any rate, it seems to me that we gain quite a bit of security at the
cost
> of
> > a little disk space.
>
>
> If you encrypt, what key do you use? If the attacker figured it out
(using
> whatever means), he could take the password file, and decrypt it, giving
him
> all the passwords.
>
> --
> poncho
>
Sorry, I didn't mean to literally encrypt, but to use the multi-DES "hash"
(which is really just a one-to-one function) and hash each block of the
password. In crypt(), the hash is done by iterating DES on the plaintext
0x0000.... and using the password to form the key for these DES operations.
The key is 56-bit, regardless of the size of the password. I merely submit
that we use the whole password by breaking it up into 56-bit chunks and
using each chunk as a key for a separate DES encryption.
======================
www.daverudolf.ca
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Good crypto or just good enough?
Date: Wed, 30 May 2001 21:06:00 +0000 (UTC)
Roger Schlafly wrote:
>In which case it is theoretically possible that 3-key 3DES is less
>secure than 2-key 3DES.
Yes, I believe so.
------------------------------
From: "Dj Le Dave" <[EMAIL PROTECTED]>
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Wed, 30 May 2001 21:06:02 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Dj Le Dave wrote:
> >
> > Related to this, I always wondered why UNIX (and other such systems)
bother
> > to hash at all. Could they not just "encrypt" the entire password, so to
> > speak? Break it up into 56-bit blocks (or whatever) and perform the hash
> > independantly on each block, then concat. all the output together to
form
> > the password file entry. This way, an attacker would have to essentially
> > have to do a plaintext-cyhertext attack on each block to get the whole
> > password. Thus, if the password is X bits long, then the attacker would
have
> > to brute-force all X bits (well, except for dictionary attacks, etc.).
And,
> > we don't run into the birthday-paradox, as DES is a one-to-one function.
At
> > any rate, it seems to me that we gain quite a bit of security at the
cost of
> > a little disk space.
>
> The problem with breaking the hash into smaller pieces (i.e encrypting
> 56-bit blocks) is the attack amounts to a linear amount of 2^28 work.
> For example if you used two 56-bit hash values instead of one big
> 112-bit hash the work required to find the password or equivalent
> passwords is 2^29 trials. Compared to 2^56 work required against the
> 112-bit hash ...
>
> Which is why a login should really use a 128-bit or more hash with a
> 64-bit salt or so. Enough to make dictionary attacks against a whole
> slew of passwords infeasible. Note that salts don't slow down the
> search for a single password, only multiple.
>
> Tom
Ah, yes. Silly me. Since they have both plain and cyphertext, they can
attack each block independantly. That's the kind of slap in the face that I
needed. Many thanks.:)
======================
www.daverudolf.ca
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: differential oddity
Date: Wed, 30 May 2001 21:38:00 GMT
Here's a neat question. In a finite function that has differentials
(input/output xor pairs) of probability one is a standard differential
attack possible?
In DES IIRC the idea is to send in random pairs, when the difference
occurs you use linear algebra to figure out from "I sent in these values
but these are the values that are suppose to cause the difference"...
i.e
(1) if a,b cause the difference X => Y (a xor b == X) and you send in
c,d then the key must be K=c^a (suppose the key is xored in).
(2) In other attacks they use "if this difference did [not] occur the
key is [in]valid" (such as my attack on MDFC).
However, what if you have F(x) = 5x or something to that effect. The
difference F(x) - F(x - c) = 5c will occur with a probability of one.
Thus can that even be used?
I can see how that's non-random, but in both cases (1) and (2) the
results are going to be fixed before hand...
Tom
------------------------------
From: Sam Yorko <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Wed, 30 May 2001 14:59:05 -0800
JPeschel wrote:
>
> Hmmm... my bother-in-law at Ft Meade sent me this one.
>
> http://cbsnews.com/now/story/0,1597,266857-412,00.shtml
>
> Joe
> __________________________________________
>
> Joe Peschel
> D.O.E. SysWorks
> http://members.aol.com/jpeschel/index.htm
> __________________________________________
I've been wondering: if someone claims to be from the NSA, how can you
verify that? I don't think it's possible.
Sam
------------------------------
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
From: (chenshaw<RE<MOVE>@(T<H+ESE)sympatico.ca) (Coridon Henshaw)
Date: Wed, 30 May 2001 21:56:06 GMT
"Roger Schlafly" <[EMAIL PROTECTED]> wrote in news:P37R6.79
$[EMAIL PROTECTED]:
> DRM = Digital Rights Management. The music industry would
> like to use this to sell music over the net, but restrict the user
> from giving copies to his friends.
That's the theory, anyway. In practice DRM will likely require a 'call
home' (and possibly additonal payment) every time music is played, prevent
the resale of used music, tie music to one specific computer or player
device, and (under the DMCA) criminalize the backup of legally purchased
music. In other words, DRM is the music publishers' ultimate cash cow.
Instead of buying one CD that can be used in their car, home stereos,
computers and portable players, the consumer will need to 'buy' (really
rent) one 'license' for each and every device--even if only once device is
used at once. If any of these devices fail, a new 'license' will be
needed. DRM is fraud and theft, plain and simple.
--
Coridon Henshaw -- http://www3.sympatico.ca/gcircle/csbh
"..To expect a good deal from life is puerile." -- D.H. Lawrence
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Wed, 30 May 2001 22:01:34 GMT
Sam Yorko wrote:
>
> JPeschel wrote:
> >
> > Hmmm... my bother-in-law at Ft Meade sent me this one.
> >
> > http://cbsnews.com/now/story/0,1597,266857-412,00.shtml
> >
> > Joe
> > __________________________________________
> >
> > Joe Peschel
> > D.O.E. SysWorks
> > http://members.aol.com/jpeschel/index.htm
> > __________________________________________
>
> I've been wondering: if someone claims to be from the NSA, how can you
> verify that? I don't think it's possible.
I dunno, but I think for the most part you are not required to deny you
work for the NSA. Even if they did/do work for the nsa what does that
mean? They could just be secretaries or file clerks. They are not
really the 007 clone ...
Tom
------------------------------
From: "Peter Schurman" <[EMAIL PROTECTED]>
Subject: question: how does brute force key search work?
Date: Thu, 31 May 2001 00:03:53 +0200
Hi,
I am interested in what it takes to calculate a 56 bits DES key using brute
force search.
How long does it takes and how many PC's should be used in that case.
Thereoretical it takes a few years I guess, but there must be another way?
Thanks in advance,
Peter.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: question: how does brute force key search work?
Date: Wed, 30 May 2001 22:06:55 GMT
Peter Schurman wrote:
>
> Hi,
>
> I am interested in what it takes to calculate a 56 bits DES key using brute
> force search.
> How long does it takes and how many PC's should be used in that case.
> Thereoretical it takes a few years I guess, but there must be another way?
Generally you exploit the language redundancy. If it's english you
throw away all keys that decrypt it to non ascii blocks. In the case of
DES about 1/256 keys will randomly decrypt to non-ascii blocks. From
that you throw away (or give less priority too) keys that decrypt blocks
to include digraphs like TZ and MP and etc... What's left will most
likely be the key.
Of course that takes quite a while... not a couple of years though...
Tom
------------------------------
From: Sam Yorko <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Wed, 30 May 2001 15:07:38 -0800
Tom St Denis wrote:
>
> Sam Yorko wrote:
> >
> > JPeschel wrote:
> > >
> > > Hmmm... my bother-in-law at Ft Meade sent me this one.
> > >
> > > http://cbsnews.com/now/story/0,1597,266857-412,00.shtml
> > >
> > > Joe
> > > __________________________________________
> > >
> > > Joe Peschel
> > > D.O.E. SysWorks
> > > http://members.aol.com/jpeschel/index.htm
> > > __________________________________________
> >
> > I've been wondering: if someone claims to be from the NSA, how can you
> > verify that? I don't think it's possible.
>
> I dunno, but I think for the most part you are not required to deny you
> work for the NSA. Even if they did/do work for the nsa what does that
> mean? They could just be secretaries or file clerks. They are not
> really the 007 clone ...
>
> Tom
I guess what I really meant is if someone confronted me with an NSA
badge, how in the world could I verify this? What does a real NSA badge
look like? Who could I call to verify he was how he said he was?
(social engineering, and all).
Sam
------------------------------
From: "Jordan C. Wiseman" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Wed, 30 May 2001 22:11:48 GMT
Actually, I do....there are several medical
institutions that use Citrix boxes with
high-encryption....Dumb terminals that have no
floppy (or any other drive) and only route
connections to the Citrix box from
internal/private IP's on certain subnets.
While this is not perfect, it would seem to me
that this kind of system would make securing the
medical data easier...especially since all of it
would reside in a single place that would be
easier to physically secure.
Jordan
"Roger Schlafly" <[EMAIL PROTECTED]>
wrote in message
news:PRbR6.770$[EMAIL PROTECTED].
..
> "Larry Kilgallen"
<[EMAIL PROTECTED]> wrote in
message
> news:[EMAIL PROTECTED]...
> > In article
<P37R6.79$[EMAIL PROTECTED]>,
"Roger Schlafly"
> <[EMAIL PROTECTED]> writes:
> > > Once a medico has computer access to a
digital record, it is very
> > > difficult to keep him from making
unrestricted copies.
> > It depends on what you mean by "very
difficult". If they want it
> > on computer media, they would have to attach a
drive to the workstation
> > they use to access the data. The would also
have to break into the
> > application that presents the results to them
on that workstation.
> > Of course if an organization tries to take
stock Microsoft machines
> > and uses file transfer to deliver results to
them, all bets are off,
> > but organizations that take no precautions in
this regard are not
> > worth discussing.
>
> Do you know of an organization that keeps all
its medical (or similar)
> data on a cryptographically secure network, and
the only possible
> read access is on a screen or some other medium
that is not easily
> copied? If so, I am pleasantly surprised.
>
> Do it handle data coming in and out of the
organization in a secure
> manner? Tell me more. The average US hospital is
probably 20
> years away from doing anything like that.
>
>
>
>
>
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Wed, 30 May 2001 22:12:49 GMT
Sam Yorko wrote:
>
> Tom St Denis wrote:
> >
> > Sam Yorko wrote:
> > >
> > > JPeschel wrote:
> > > >
> > > > Hmmm... my bother-in-law at Ft Meade sent me this one.
> > > >
> > > > http://cbsnews.com/now/story/0,1597,266857-412,00.shtml
> > > >
> > > > Joe
> > > > __________________________________________
> > > >
> > > > Joe Peschel
> > > > D.O.E. SysWorks
> > > > http://members.aol.com/jpeschel/index.htm
> > > > __________________________________________
> > >
> > > I've been wondering: if someone claims to be from the NSA, how can you
> > > verify that? I don't think it's possible.
> >
> > I dunno, but I think for the most part you are not required to deny you
> > work for the NSA. Even if they did/do work for the nsa what does that
> > mean? They could just be secretaries or file clerks. They are not
> > really the 007 clone ...
> >
> > Tom
>
> I guess what I really meant is if someone confronted me with an NSA
> badge, how in the world could I verify this? What does a real NSA badge
> look like? Who could I call to verify he was how he said he was?
> (social engineering, and all).
This is the same question as in "If I met god how could I verify it?".
The answer is "It doesn't matter". Even if you are totally 100%
convinced he is from the nsa would it change your life in the least?
Nope.
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Wed, 30 May 2001 14:45:17 -0700
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9f3lk0$1kqu$[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> >Proving that 3DES is at least as secure is performed easily by relating
the
> >keys, in particular by setting all keys to the same value and assuming
EDE
> >(which is the norm, and the specification).
>
> This is not allowed---you have changed the problem.
>
> It is implicit in the description of most encryption algorithms
> that keys are generated uniformly at random from the keyspace;
> for 2-key 3DES, this is a 112-bit keyspace, and for 3-key 3DES,
> this is a 168-bit keyspace.
Well then let me change it a bit. We have two cases, the first case is where
the first and second key are the same, the result is straight DES.
The second case is where the first and second key are different, this
results in a construct of the form DES followed by something. If that
something weakened DES the something could be applied by an adversary, so
DES can be no stronger than 3DES.
Those are complete cases, and in both cases it was proven that DES cannot be
stronger than 3DES. Therefore 3DES must be at least as strong as DES.
This assumes that the keys are selected independently, if the keys are
chosen in a dependent fashion there may be issues.
Joe
------------------------------
From: "Dave Rudolf" <[EMAIL PROTECTED]>
Subject: PGP Weakness???
Date: Wed, 30 May 2001 22:28:20 GMT
Hi all.
I heard mumbling rumours of a flaw in the PGP algorithm that reduces its
analysis time. I have found stuff about implementation/platform security
holes, etc., but nothing about the pure algorithm. Has anyone else seen or
heard anything about this?
======================
www.daverudolf.ca
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: National Security Nightmare?
Date: 30 May 2001 22:16:18 GMT
[EMAIL PROTECTED] (Sam Yorko) wrote in
<[EMAIL PROTECTED]>:
>
>I guess what I really meant is if someone confronted me with an NSA
>badge, how in the world could I verify this? What does a real NSA badge
>look like? Who could I call to verify he was how he said he was?
>(social engineering, and all).
>
What difference does it make. So the asshole says he is from
the NSA. So what he has no power to tell you to do anything. If
the guy acts like an ass I guess you have to call a lawyer and
take the bastard to court. Sooner or later it will be obvious
if the guy worked for the NSA. It would be far easyer for the guy
to say he worked for Ben Laden ( sorry bad spealling) he doesn't
need a badge he just speaks with an arab accent and holds a knife
to your wifes throat. I think you would be satisfied with his
claim and not ask for more ID.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 30 May 2001 22:32:53 GMT
Subject: Re: National Security Nightmare?
> Sam Yorko [EMAIL PROTECTED] writes, in part:
>I guess what I really meant is if someone confronted me with an NSA
>badge, how in the world could I verify this?
Don't worry. No one will.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Mark Lomas" <[EMAIL PROTECTED]>
Subject: Re: Cool Cryptography Website!
Date: Wed, 30 May 2001 23:36:00 +0100
"John Savard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 30 May 2001 16:31:40 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote, in part:
>
> >If someone does a verbatim copy, there is good evidence
> >that he copies from you.
>
> Isn't it equally good evidence that I copied from him?
>
> If he instead decides to be the original author of something for which
> my writings were merely a source of information, then he would have
> done nothing more than I myself have done. But to a multitude of
> victims...that, and putting everything in my own words, is what makes
> it "research".
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/frhome.htm
Plagiarize,
Let no one else's work evade your eyes,
Remember why the good Lord made your eyes,
So don't shade your eyes,
But plagiarize, plagiarize, plagiarize...
Only be sure always to call it please, "research".
Tom Lehrer - "[Nicolai Ivanovich] Lobachevsky"
Giving this a citatation seems odd :-)
Mark
------------------------------
** 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
******************************
