Cryptography-Digest Digest #10, Volume #12 Mon, 12 Jun 00 14:13:00 EDT
Contents:
Re: Encryption implimentation in windows - downsides? (ie: temp files, virt memory,
etc) ([EMAIL PROTECTED])
Man in the middle attacks ([EMAIL PROTECTED])
Re: Observer 4/6/2000: "Your privacy ends here" (Charles Lindsey)
a couple of qutions on 3DES (dexMilano)
Re: CRC Programming Help... Please!! (Scott Nelson)
Re: slfsr.c (Simon Johnson)
Re: FIPS-186 vs. FIPS-186-2 ("Martin Hamann")
Re: Random sboxes... real info (tomstd)
Re: Improving DES based MAC ("Scott Fluhrer")
Re: Multiple encryptions (James Felling)
Re: Question (Mike Rosing)
Re: CAST sboxes --- scarry (Alex MacPherson)
Re: Encryption implimentation in windows - downsides? (ie: temp files, virt memory,
etc) (zapzing)
Re: Secret Spliting - Theshold shemes. (Mike Rosing)
Re: help for rc5 cryptanalysis (James Felling)
Re: Random sboxes... real info (Tim Tyler)
Re: FIPS-186 vs. FIPS-186-2 (DJohn37050)
Re: Good ways to test. (Tim Tyler)
Re: a couple of qutions on 3DES (tomstd)
Re: Man in the middle attacks (Mike Rosing)
Re: Cryptographic voting (zapzing)
Re: Is it possible to use encryption to solve this problem? (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption implimentation in windows - downsides? (ie: temp files, virt
memory, etc)
Date: Mon, 12 Jun 2000 15:55:45 GMT
In article <8hts0m$qq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> * When I decrypt a file, read it, then encrypt it again, is it not the
> case that some part (if not all) of the decrypted file will be left in
> widows virtual memory or some kind of temp files?
On most systems, this is practically a given. However, you can turn off
use of swap files on individual computers. (I don't run windows any
more, but I think under both NT and 9x you can get there by
right-clicking the "My Computer" icon and hitting Properties..)
As for the temp files, that depends on the application. MS Word, you
bet; I have seen files left over in \temp, in \windows\temp, as
~filename.doc, etc. Software such as Norton Undelete can tell you when
files have been "deleted" but their data still exists -- so I know it is
possible to find these files after the fact, and trash them then.
> * I want to have a database of encrypted documents, and want them
> stored (and used) as securly as possible - should I (a) encrypt the
> documents individually and have also an encrypted TOC file so I
> minimise the danger of 'left overs' when encrypting / decrypting, or
> should I encrypt the entire collection of documents in one block and
> crypt/decrypt them when I start and then terminate my program
My suggestion -- allow for as fine a grain of locking as possible.
Encrypting each individual document with a different key is likely the
thing to do, though you must figure some effective way of dealing with
the keys.
> * Finally, is there any methology known (for windows based os) for
> determining what has gone into virtual memory so I can wipe over those
> blocks after re-encryption ?
To the best of my knowledge, no -- I don't think applications are ever
aware when they have been swapped out. I could be wrong, I never did
program Windows much.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Man in the middle attacks
Date: Mon, 12 Jun 2000 15:59:29 GMT
I've been reading my copy of Applied Cryptography, looking at ways of
defeating man in the middle attacks.
All the methods in the book use a Trusted Person to make sure the
protocol works.
Can anyone please point me in the direction of a protocol that works
with two nodes - if such a thing exists. It's been rattling around in
my head for the last week and I can't think how I would make it work.
Thanks,
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
From: [EMAIL PROTECTED] (Charles Lindsey)
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Mon, 12 Jun 2000 11:31:37 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (U
Sewell-Detritus) writes:
>>Universal Declaration of Human Rights
>>...
>>Article 11
>>
>>(1) Everyone charged with a penal offence has the right to be presumed
>>innocent until proved guilty according to law in a public trial at which
>>he has had all the guarantees necessary for his defence.
>*IANAL*
>Doesn't look like the ECHR is a good place for the UK to test the water
>on the legality of RIP.
Actually, it should be a very good place. See
<http://www.fipr.org/rip.ripaudP3.html>
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: [EMAIL PROTECTED] Web: http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: a couple of qutions on 3DES
Date: Mon, 12 Jun 2000 16:17:49 GMT
Do you know if there are some constrains among 3 keys for use them into
3des?
Do you know where can be available a source code in C or Java for
DES/3DES?
thx
dex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: CRC Programming Help... Please!!
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Jun 2000 16:36:54 GMT
On Sun, 11 Jun 2000 21:08:42 GMT, [EMAIL PROTECTED] (gKw-X) wrote:
>hey guys!
>
>i have some questions regarding crc computation... an answer to any
>extent to these qs would be greatly appreciated :)
>
>if one program uses certain variables to create the crcs, and you
>can't see what they are directly, is there any way to determine the
>variables that go into it by somehow 'reverse engineering' the crc
>outputs for different files? (so that you can then support the outputs
>of other programs)
>
If it really is a CRC (sometimes people use other checksumming
methods and mistakenly label them CRC) and it's small enough,
then you can just brute force the answer. If the CRC is
larger than 32 bits, then this is problematic.
If you can select the file to be CRC'ed, then a single 1 followed
by N-1 zeros will essentially output the poly.
There are a few "common" values used for CRC's,
and it's likely that it's one of these;
32,26,23,22,16,12,11,10,8,7,5,4,2,1,0
32,31,27,26,25,19,16,15,13,12,11,9,7,6,5,4,2,1,0
32,23,21,11,2,0
16,15,2,0
16,14,1,0
The initial CRC value is usually either all 0's or all 1's.
>does anyone know where i could find some crc code that's flexible
>enough to allow you to modify those variables? all the code i've found
>is hard to work with in that respect....
>
You mean something like this:
=========================
#include <stdio.h>
#define EOR_VAL 0xa001
#define uint unsigned int
uint calc_crc(uint old_crc, uint byte) {
int i;
for (i=0; i<8; i++) {
if ( ((byte ^ old_crc) & 1) == 1) {
old_crc = old_crc>>1 ^ EOR_VAL;
} else {
old_crc = old_crc>>1;
}
byte >>= 1 ;
}
return old_crc;
}
int main(int argc, char *argv[]) {
int val;
uint crc;
crc = 0;
while (*++argv) {
sscanf(*argv, "%x", &val);
crc = calc_crc(crc, val);
printf("%02x %04x\n", val, crc);
}
return 0;
}
=========================
No, I don't know of anything like that on the web.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
Subject: Re: slfsr.c
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 12 Jun 2000 09:32:47 -0700
Generally a slfsr can't be worked backwards given only the output
Tom
Just a small nitpick :)
You wouldn't have to skip outputs if LFSRs didn't *leak*
information about it's internal state. Though your probably
correct in saying, this generally can't be exploited.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Martin Hamann" <[EMAIL PROTECTED]>
Subject: Re: FIPS-186 vs. FIPS-186-2
Date: Mon, 12 Jun 2000 18:26:59 +0200
Reply-To: "Martin Hamann" <[EMAIL PROTECTED]>
> I'm not sure 186-2 is actually published yet. I'd have thought it'd be
> on NIST's web pages by now if it were.
>
> http://www.itl.nist.gov/fipspubs/by-num.htm
>
> suggests that 186-1 is the latest, published on 1998-12-15.
I found this on the web
http://csrc.nist.gov/fips/fips186-2.pdf
It's official date is 27th of july 2000, but as far as I can see it is
published already.
Regards
Martin
------------------------------
Subject: Re: Random sboxes... real info
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 12 Jun 2000 09:34:33 -0700
In article <8i301b$8ic$[EMAIL PROTECTED]>, sarnold_intertrust@my-
deja.com wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> I.e is my point comming through? Random sboxes are hardly
ideal.
>
>Ok Tom -- new assignment. Random S-boxes are bad. So, write some
>software to output "ok" S-boxes. (Save the program to
output "good" and
>"great" sboxes either for yourself, or to sell. :)
>
>:)
You truly are blind to the world?
Check out
http://tomstdenis.com/sboxgen.c
It's been there for about two months, and I have mentioned it on
numerous occasions...
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Improving DES based MAC
Date: Mon, 12 Jun 2000 09:22:31 -0700
Tor Rustad <[EMAIL PROTECTED]> wrote in message
news:JF315.24972$[EMAIL PROTECTED]...
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
>
> > I suspect the attacker might be able to do something to reduce the work
> > effort if he had lots on plaintext/ciphertext pairs. Or, someone might
be
> > more clever than me. You must admit, that is an extremely likely
> > possibility :-)
>
> Well, the rest of this news group has been very silent, and it is not even
> shure that such an attack do exist... But I feel there is a danger that a
> chosen plaintext attack and cryptoanalyze, migth reduce the security
below
> 2^56...
I just realized that it is possible to get the security down to O(2^56) with
256 chosen plaintexts. The mode we're talking about is:
> C = k XOR (DESk( k XOR P ))
The official definition of DES takes a 64 bit key, and ignores the LSBit of
each byte ("uses them for parity checks"). And so, chose 256 plaintexts
that iterate over all possible settings of the LSBits, and holds all the
other plaintext bits the same. Then, that gives you an efficient test for a
56 bit key. Set the LSBits of the key (the bits that don't contribute to
the real DES key) to an arbitrary value, xor in the 56 bit known value, send
it through DES, and xor in the 56 bit known value. If the key was correct,
56 of those bits will match one of the 256 ciphertexts that you were given.
--
poncho
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Multiple encryptions
Date: Mon, 12 Jun 2000 12:15:13 -0500
Guy Macon wrote:
> James Felling wrote:
>
> >So long as D and E do not work by similar mechanisms there will be
> >little risk of this occurring though -- effectively 0 if you choose
> >D and E with care.
>
> I fully agree with the above. I, of course, am a clueless newbie
> who lacks the ability to choose the two methods with care, and the
> top crypto experts may make a mistake when choosing the two methods
> with care. The probability of them doing so is almost certainly
> higher than the probability of the first method being cracked.
I don't know about that. Examine them with a reasonable amount of scrutiny
-- if one uses MXN Sboxes then the other shouldn't -- but KxL sboxes are
probably OK, if one uses data dependent rotations, the other shouldn't,
maybe make one a stream cypher and the other a block cypher -- that kind
of thing. If you can manage this (and I am confident that you can) it is
still POSSIBLE that you might have some element of relation between the
two, but frankly the odds of that are much lower than the odds of your
being struck by lighting -- repeatedly.
>
>
> That being said, I think that I can prove that the two methods are
> unrelated and therefor not weaker than either one alone if one of
> the methods it OTP. I have a gut feeling that making the two methods
> symmetric key and asymmetric key will make them unrelated, but I can't
> prove it.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Question
Date: Mon, 12 Jun 2000 12:12:23 -0500
[EMAIL PROTECTED] wrote:
>
> how do you find out an algorithm of a file that you cannot compare to
> with samples from the program it was encrypted with. I cant use
> dictionary files or the brute force method to decrypt it. I would
> appreciate any help i could get thank you.
One way is to do a hex dump of several files from each of several
programs
you know about. The first few bytes should look the same or similar for
the same program. Then compare the file you don't know about with
these.
That should give you some idea which program encrypted the data.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Alex MacPherson <[EMAIL PROTECTED]>
Subject: Re: CAST sboxes --- scarry
Date: Mon, 12 Jun 2000 13:26:06 -0400
http://saturn.ee.queensu.ca:8000/cast/
--
Alex MacPherson
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Encryption implimentation in windows - downsides? (ie: temp files, virt
memory, etc)
Date: Mon, 12 Jun 2000 17:24:41 GMT
In article <8hts0m$qq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi,
>
> I have been reading a lot about the things to watch for when
> implementing an encryption system, and the following thoughts struck
me:
>
> * When I decrypt a file, read it, then encrypt it again, is it not the
> case that some part (if not all) of the decrypted file will be left in
> widows virtual memory or some kind of temp files?
>
> * I want to have a database of encrypted documents, and want them
> stored (and used) as securly as possible - should I (a) encrypt the
> documents individually and have also an encrypted TOC file so I
> minimise the danger of 'left overs' when encrypting / decrypting, or
> should I encrypt the entire collection of documents in one block and
> crypt/decrypt them when I start and then terminate my program
>
> * Finally, is there any methology known (for windows based os) for
> determining what has gone into virtual memory so I can wipe over those
> blocks after re-encryption ?
>
> thanks!
If you use hardware encryption, placed between your
CPU/RAM and your Hard disk/IO devices, then there
is no need to worry about what the stupid MicroSerf
OS is doing. I think it is ironic that Bill Gates is
getting burned because he did not encrypt his email
securely enough.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Secret Spliting - Theshold shemes.
Date: Mon, 12 Jun 2000 12:25:29 -0500
Simon Johnson wrote:
>
> Just to insure you know what i'm talking about, i'll include the
> description of the threshold sheme i am refering to:
>
> To split message C, amoung x users such that n shadows can recover the
> message do the following:
>
> 1.) Choose a number greater than C (a prime would be optimal) for the
> mod, p.
>
> 2.) Choose random coeffients for the following equation
>
> t = ax^n-1 + bx^n-2 ......... + c mod p
>
> 3.) increment X and calculate t to generate the shadows.
I'm not following this, but for a (k,n) threshold scheme there are a lot
of papers in CRYPTO and EUROCRYPT. I've never gotten into it, but sure
looks like fun :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: help for rc5 cryptanalysis
Date: Mon, 12 Jun 2000 12:27:08 -0500
Just a note in addition not all key/plaintext pairs produce a valid "Encrypted
plaintext" with 8-rounds of non- rotated RC5.
E.g. All S's are 0. then All plaintexets encode to 0.
In addtion the low bit of either half is in NO WAY PLAINTEXT DEPENDENT. This
means at best what we have here is a hash.
Either that or I missed something.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Jun 2000 17:23:44 GMT
[EMAIL PROTECTED] wrote:
: tomstd <[EMAIL PROTECTED]> wrote:
:> I.e is my point comming through? Random sboxes are hardly ideal.
: Ok Tom -- new assignment. Random S-boxes are bad. [...]
Lots of folk like random s-boxes. To quote from BS's AC (p. 351):
``my personal feeling is that S-boxes should be as large as possible,
random and key-dependent.''
I don't usually number myself among lovers of large s-boxes - but large
random s-boxes aren't exactly bad. In fact they're usually very good -
and the bigger they are the better they are, in terms of strength.
Tom was closer to the mark - random s-boxes are rarely *ideal*.
But what is an ideal s-box? The designers of DES had one idea - we now
know they were wrong.
The "desirable" attributes of s-boxes are contradictory and pull in
different directions. The resulting boxes are always compromises -
emphasising one aspect at the expense of something else. The very act of
constraining s-boxes means the analyst has less potential candidate
s-boxes to consider if he attempts to consider all possibilities for that
component.
At least large random s-boxes are unlikely to be systematically weak.
It's pretty hard to claim this about any constrained subset of s-boxes,
in the light of the possibility of unknown cryptanalytic attacks from
future analysts, or simply ones who do not publish their results.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: FIPS-186 vs. FIPS-186-2
Date: 12 Jun 2000 17:43:48 GMT
186-2 adds the methods found in ANSI X9.31 rDSA (RSA/RW) and X9.62 ECDSA to the
method found in ANSI X9.30 DSA. BTW, DSA is being modified to increase key
length and a new hash function (sometimes referred to as SHA-2) is coming out
also with longer lengths.
Don Johnson
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Good ways to test.
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Jun 2000 17:30:46 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: What about provably secure block ciphers [...]
There's no such beast.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
Subject: Re: a couple of qutions on 3DES
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 12 Jun 2000 10:43:02 -0700
In article <8i32eu$ac4$[EMAIL PROTECTED]>, dexMilano
<[EMAIL PROTECTED]> wrote:
>Do you know if there are some constrains among 3 keys for use
them into
>3des?
The 168 bit key should be uniformly distributed over {0, 1}
^168. However that goes for any block cipher.
>Do you know where can be available a source code in C or Java
for
>DES/3DES?
Probably CryptoLib (Crypto++, etc..) but des and 3des are pure
evil ciphers. They are slow, cumbersome and not particularly
good for much.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Man in the middle attacks
Date: Mon, 12 Jun 2000 12:42:18 -0500
[EMAIL PROTECTED] wrote:
>
> I've been reading my copy of Applied Cryptography, looking at ways of
> defeating man in the middle attacks.
>
> All the methods in the book use a Trusted Person to make sure the
> protocol works.
>
> Can anyone please point me in the direction of a protocol that works
> with two nodes - if such a thing exists. It's been rattling around in
> my head for the last week and I can't think how I would make it work.
That's because it can't be done. You must have multiple channels and
use
them all simultaneously and hope the attacker can't break them all. If
the attacker can get in the middle of all channels, you're screwed.
So, one channel an attacker can't get in the middle of is a face to face
meeting. They can tap it and video watch, but they can't substitute.
However, if you don't know *who* you're meeting face to face, it might
be
a spy. And you're still screwed :-)
You can only raise the price of an attack. You can never stop it.
Patience, persistence, truth,
Dr. mike
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Mon, 12 Jun 2000 17:39:24 GMT
In article <8i1jj8$c5l$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
>
> > For goodness sakes, people could use laundry
> > tickets for money if they wanted to. Actually
> > that gives me an interesting idea about
> > cryptographic money .... I'll have to work on
> > it after I get the *cryptographic* *voting*
> > thing figured out (hint).
>
> After carefull consideration of what would be required for a voting
> system to resist fraud and tampering, I have come to the conclusion
> that given the requirements below, one cannot be made:
>
> 1. It must be secret ballot
> 2. Voters cannot be identified (by law)
> 3. Voters cannot be deduced from the votes
> 4. Votes must be verifiable (not altered) by anyone
> 5. Voters cannot vote more than once
> 6. The system requires no trust of anyone
>
> If you think this through, you will realize that if we don't know WHO
> voted, then we don't know with any certainty how many votes we should
> see. Therefore, the system allows a person (in charge of a precinct)
> to add any number of fraudulent votes to further their agenda.
I agree. I think though that if we *do* know
ahead of time who should be voting, and if
everyone knows these people's public
authentication keys, then a cryptographic
voting scheme might be possible.
I am working on a protocol that will do just
that. It depends on the "card shuffling
protocol" which I believe I saw mentioned
someplace. If noone has heard of a card
shuffling protocol, then I will post my
version of one.
> Requirements 1 and 2 are by law and they stand in the way (I wonder
> why?) of a fraud proof system. All other requirements can be met with
> trivial use of web sites, public keys, and other standard technology
of
> today. I can go through the steps if anyone is interested, but under
> current law, a fraud proof system cannot be used in US elections.
We may be thinking about entirely different
things. I was thinking more in terms of a
small cabal of cryptographers who wanted
to vote secretly over the internet on where
to go for dinner.
> --
> Tyranny is kept at bay by guns and will. Our government
> knows we have the guns, but they don't know if we have
> the will. Nor do we.
> The only lawful gun law on the books- the second amendment.
Personally I think cryptography works better than
guns. for a gun to work you first must know
*who* to shoot. Then you have to be there with
your gun, get him before he gets you ...
All very messy.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is it possible to use encryption to solve this problem?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Jun 2000 17:49:56 GMT
Paul <[EMAIL PROTECTED]> wrote:
: We want to have an application that users can buy.
: We also can provide add-ons to the application.
: We want to be able to sell these add-ons over the Internet via a
: subscription service.
: However, we want to make sure that one user doesn't simply pay for the
: add-ons and then simply give them away to others, bypassing the
: subscription service.
: Now my question is, what is the best way to try to go about doing
: this? Could encryption technology help us? This doesn't seem to be
: strictly a cryptographical issue, but seems to be related to it. If
: cryptography isn't part of the solution, what might be?
One traditional solution is the dongle.
Dongles are hard-to-copy physical devices, with embedded IDs.
By contrast most forms of software are relatively easy to make copies of.
Another common solution is to copyright your software - and then use the
taxpayer's money to try to enforce legal sanctions against those who
copy your software.
This approach is normally extremely ineffective, since you have no control
over the legal machinery, can't influence who perfoms searches, or what
they look for, and because there are so many copyright violations and most
of the prosecutions target corporate infringments - since targetting
end-users costs more money than it recovers.
Many folks simply tolerate piracy - since there's not much they can
do about it - hoping to translate it into future custom when upgrades
and bug-fixes come out - or when the clients need technical support.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
** 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
******************************
