Cryptography-Digest Digest #144, Volume #10 Mon, 30 Aug 99 20:13:03 EDT
Contents:
Re: On employing message-decoys (Sundial Services)
Re: Can I export software that uses encryption as copy protection? (Eric Lee Green)
Re: WT Shaw temporarily sidelined (SCOTT19U.ZIP_GUY)
Re: WT Shaw temporarily sidelined (SCOTT19U.ZIP_GUY)
Re: Excerpts from the EAR & BXA Regs regarding Encryption Software (SCOTT19U.ZIP_GUY)
Re: 512 bit number factored (Ed Stone)
Re: WT Shaw temporarily sidelined (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
Date: Mon, 30 Aug 1999 15:40:16 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: On employing message-decoys
Mok-Kong Shen wrote:
>
> [EMAIL PROTECTED] wrote:
> >
>
> > 1. How does Bob know which message is correct? There needs to be a way
> > for Bob to know what the correct message is without it being to obvious.
> > Beginning a message with "Hey Bob, this is the right one!" is not very
> > effective.
>
> Agreeing on a certain hint to help is not necessary. The recepient
> of course has much more work to do than in case of no dummy messages.
> If he tries the correct key and only one plaintext comes out to be
> readable (the keys encrypting the dummy messages need not be known to
> him), that must be (theoretically: almost certainly is) the true
> message.
The possibility also exists that the "correct" message might not arrive
at its destination, or that it will not be distinguishable from the
phonies. And what if the message is garbled and must be re-sent for
some reason? You are also taking up bandwidth sending the dummies, as
well as time to generate the dummies etc, all of which is interfering
with the communication process overall.
Unless you are trying to conceal the very fact that a message is being
passed -- which is, I think, the idea behind the Cuban numbers-stations
-- then the best approach is probably to use an algorithm that, you are
as certain as you can be, cannot be broken within the 24 hour lifespan
of the data.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: misc.legal.computing
Subject: Re: Can I export software that uses encryption as copy protection?
Date: Mon, 30 Aug 1999 15:55:04 -0700
"Trevor Jackson, III" wrote:
> Eric Lee Green wrote:
> > it is physically on my disk. I don't even necessarily have to
> > replay it. The first major program that I ever wrote was a commenting
> > disassembler (i.e., you could add comments that went with various memory
> > addresses), and then I could patch the binary directly on the disk prior
> > to loading it.
>
> OF COURSE it's easy to patch a disk image. That's like solving a monoalphabetic
>cipher.
> Trivial. Your success in patching programs is to your credit, but solving easy
>problems
> does not support your contention that all problems are as easy to solve.
All I'm noting is that encrypting the license key portions of your
program is going to be more of a nuisance factor than anything else.
It'll stop a few script kiddies at best, but "real" crackers will view
it as a challenge and swiftly strip out the license portion of your
code.
> > They failed. If I have physical access to your
> > > > software, I can load it into a binary debugger, trace its execution, and
> > > > 'break' it.
>
> You might be able to, but it wouldn't be as simple as the sentence above. For
>instance,
> if you are tracing from point to point with breakpoints, you'll have a bit of trouble
> with the code that stomps the breakpoint trap vector and breakpoint trap handler.
>If you
> are single stepping, you'll have a bit of trouble with the code that stomps the trace
> trap vector and handler.
Yawn. That's the code you binary-patch a "JMP" around. I know (former)
crackers who used to do that in their sleep. (Or at least at a time of
night when they SHOULD have been asleep!).
> > It requires enormous hardware support only if it's not on your disk
> > drive. As I mentioned, I can disassemble it while it's not running, and
> > patch the binary directly to put a breakpoint after the end of the
> > decryption routine that jumps into the debugger.
>
> If the app fights the debugger hard enough your patch effort will be larger than the
> effort required to write the applicaiton from scratch. It will still be possible to
> crack the application, but it wouldn't be sane to do so unless you wanted bragging
> rights.
Congratulations, you just discovered that crackers aren't sane! The more
effort it takes, the more prestige that crackers get by breaking it, and
the more they'll trumpet the fact and feature your product on "warez"
sites.
> > Not on most modern operating systems. For example, Unix runs all
> > programs in a virtual machine,
>
> Really. How many versions of Unix have you used?
Let's see. BSD 4.2, BSD 4.3, FreeBSD, OpenBSD, Sys V.2, Sys V.3, Sys
V.4,
SunOS, HPUX, Solaris, Linux, Xenix, Pyramid OSx, SCO Unix... probably a
couple more that I haven't recalled at the moment, since I've been
"doing" Unix since 1985. I currently work for a Unix software house that
has ports to every major Unix platform, most of which we have in our
porting lab, and which I refer to regularly in order to, e.g., make sure
my software works properly on both little-endian and big-endian
machines.
I think you are confusing a virtual machine with a virtualized CPU. Unix
programs run on a virtual machine that consists of: memory (and only
memory that it has been allocated by the OS), and a "trap" call to enter
the operating system. That's pretty much it. If a Unix program attempts
to do things like, e.g., set interrupt vectors, or directly access a
hard drive controller, an exception will be generated and the execution
of the program suspended (what the OS does then depends on what handlers
have been set up but most probably you will NOT be setting an interrupt
vector or writing bytes to the hard drive). Thus you obviously cannot
run an operating system within the Unix virtual machine, since it is not
a virtualized CPU but rather a simplified pseudo-machine that just
happens to have a VERY intelligent "trap" call (grin).
> Most don't use virtual machines because
> virtual machines became common far later than Unix did.
Err, VM/CMS? Multics? Hmm? (I don't know about VM/CMS, but Multics
*certainly* precedes Unix). It doesn't really matter, because it appears
that we are talking about different things. You are talking about a
virtualized CPU, and I am talking about the virtual memory/system call
exception scheme that every major Unix variant uses as its virtual
machine (the only ones that I am aware of that do not are certain older,
cruder Xenix implementations, and various academic "toys" like Minix).
> Of the versions that do use virtual machines, there are always ways to escape the
> virtualization.
If you are running SUID root then you can request specific i/o ports and
such. But for normal programs you do not have that option.
> As the attacker you enjoy the attackers fundamental advantage of selecting the point
>of
> attack, where the defender, the author of the applicaiton, has to defend
>"everywhere".
> This fact does lead to a dismissal of defense as a concept.
Thank you. Actually, I think it does not rule out defense as a concept
but, rather, defense against crackers as a concept. A certain amount of
protection will keep out the script kiddies. Just don't overestimate
what can be done on a defensive basis against a detirmined cracker.
> > Cryptographic systems can only secure communications. They cannot stop
> > an attacker from viewing the plaintext by "tapping" the decryption
> > engine. Given physical access to the decryption engine, it can be rigged
> > to spit out the plaintext to me at the same time that you view it.
> > Without understanding this, you will never be able to create a secure
> > cryptographic system.
>
> If you can undetectably "tap" the decryption engine you can certainly obtain the
> plaintext. If you cannot the rest of your argument becomes moot.
Correct. I'm just pointing out that there's a number of ways to
undetectably "tap" the decryption engine on most modern operating
systems.
> All such defensive systems have to be justified in terms of cost/benefit. I'll take
>your
> word for it that the cost of more "hardening" of your code is not justified. But
>that
> has nothing to do with the possibility of such hardening being useful.
Granted. It'll keep out the script kiddies and casual browsers. But as
far as hard-core crackers, it'll just be another challenge for them to
boast about.
Given that the simplest of authentication schemes will suffice to give
the script kiddies fits, I made a cost-benefit analysis and decided that
further obfuscation was not necessary (don't get me wrong, it's a
cryptograhically strong license information authentication scheme, but
any detirmined cracker with a binary debugger and binary editor could
crack it). My boss, who got his start in a similar way, agrees, saying
"the kind of people who can defeat what you've done aren't going to buy
our product anyhow."
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: WT Shaw temporarily sidelined
Date: Tue, 31 Aug 1999 00:24:30 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>[EMAIL PROTECTED] wrote, in part:
>
>>This may be a dumb question, but what's wrong with him?
>
>I don't know; often, people don't choose to release that information.
>But he is in the hospital, and IIRC he is of advanced age.
>
what is IIRC and by advanced age do you mean older than 70.
>John Savard ( teneerf<- )
>http://www.ecn.ab.ca/~jsavard/crypto.htm
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: WT Shaw temporarily sidelined
Date: Tue, 31 Aug 1999 00:19:23 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote, in part:
>
>>I think he is in Texas
>>is he not.
>
>Yes, I think so too. And I thought you were in New York or
>thereabouts, so you probably wouldn't get the chance to just drop by.
Well as usually your wrong again. I move around and heard Clinton
was going to move there so your can forget New York. However I think the
president is sending a lot of money that way so it might be a nice place to
live. Especailly if the muderous bombers he recently pardoned are not allowed
to live there. I wonder if that was part of the deal they got. I thik it would
be disingenuous to wish him a speedy recovery on a message on the net.
I would rather say it to him in person. Since I am such a nice guy. Besides
a phony letter of good wishes is so phony and unpersonal when I think he
would apreciate a visit in person. I can even offer him a beer.
>
>But I do wish him a speedy recovery.
>
>John Savard ( teneerf<- )
>http://www.ecn.ab.ca/~jsavard/crypto.htm
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto
Subject: Re: Excerpts from the EAR & BXA Regs regarding Encryption Software
Date: Mon, 30 Aug 1999 14:15:21 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>The most significant Excerpts from the EAR & BXA Regs I found.
>
>located, searched, and posted to help all of you by Ciphile Software
>
>OAP-L3: Original Absolute Privacy - Level3 Encryption Software
>http://www.ciphile.com
>
>
>
>(7) General Prohibition Seven � Support of
>Proliferation Activities (U.S. Person
>Proliferation Activity).
>_(i) Support of Proliferation Activities (U.S.
>Person Proliferation Activity).
>(A) If you are a U.S. person as that term is
>defined in �744.6(c) of the EAR, you may not
>engage in any activities prohibited by �744.6(a)
>or (b) of the EAR, which prohibits the
>performance, without a license from BXA, of
>certain financing, contracting, service, support,
>transportation, freight forwarding, or employment
>that you know will assist in certain proliferation
>activities described further in part 744 of the
>EAR. There are no License Exceptions to this
>General Prohibition Seven in part 740 of the EAR
>unless specifically authorized in that part.
> (ii) You may not, without a license from BXA,
>provide certain technical assistance to foreign
>persons with respect to encryption items, as
>described in �744.9 of the EAR.
>
>
>�744.9
>RESTRICTIONS ON TECHNICAL
>ASSISTANCE BY U.S. PERSONS WITH
>RESPECT TO ENCRYPTION ITEMS
>(a) General prohibition
>No U.S. person may, without a license from BXA,
>provide technical assistance (including training) to
>foreign persons with the intent to aid a foreign
>person in the development or manufacture outside
>the United States of encryption commodities and
>software that, if of United States origin, would be
>controlled for "EI" reasons under ECCN 5A002 or
>5D002. Note that this prohibition does not apply
>if the U.S. person providing the assistance has a
>license or is otherwise entitled to export the
>encryption commodities and software in question
>to the foreign person(s) receiving the assistance.
>Note in addition that the mere teaching or
>discussion of information about cryptography,
>including, for example, in an academic setting, by
>itself would not establish the intent described in
>this section, even where foreign persons are
>present.
>(b) Definition of U.S. person
>For purposes of this section, the term U.S. person
>includes:
>(1) Any individual who is a citizen or permanent
>resident alien of the United States;
>(2) Any juridical person organized under the laws
>of the United States or any jurisdiction within the
>United States, including foreign branches; and
>(3) Any person in the United States.
>
>Definitions of Terms Part 772-page 6
>Export Administration Regulations
>"Cryptanalysis". (Cat 5)--The analysis of a
>cryptographic system or its inputs and outputs to
>derive confidential variables or sensitive data
>including clear text. (ISO 7498-2-1988(E),
>paragraph 3.3.18)
>"Cryptography". (Cat 5)--The discipline that
>embodies principles, means and methods for the
>transformation of data in order to hide its
>information content, prevent its undetected
>modification or prevent its unauthorized use.
>"Cryptography" is limited to the transformation of
>information using one or more "secret
>parameters" (e.g., crypto variables) and/or
>associated key management.
>Note: "Secret parameter": a constant or key
>kept from the knowledge of others or shared only
>within a group.
>Encryption items. The phrase encryption items
>includes all encryption commodities, software,
>and technology that contain encryption features
>and are subject to the EAR. This does not include
>encryption items specifically designed,
>developed, configured, adapted or modified for
>military applications ( including command,
>control and intelligence applications) which are
>controlled by the Department of State on the U.S.
>Munitions List.
>Encryption licensing arrangement. A license
>that allows the export of specified products to
>specified destinations in unlimited quantities. In
>certain cases, exports are limited to specified end-users
>for specified end-uses. Generally, reporting
>of all sales of the specified products is required at
>six month intervals. This includes sales made
>under distribution arrangements and distribution
>and warehousing agreements that were previously
>issued by the Department of State for encryption
>items.
>Encryption object code. Computer programs
>containing an encryption source code that has
>been compiled into a form of code that can be
>directly executed by a computer to perform an
>encryption function.
>Encryption software. Computer programs that
>provide capability of encryption functions or
>confidentiality of information or information
>systems. Such software includes source code,
>object code, applications software, or system
>software.
>Encryption source code. A precise set of
>operating instructions to a computer that, when
>compiled, allows for the execution of an
>encryption function on a computer.
>Export Control Classification Number (ECCN).
>The numbers used in Supplement No. 1 to part
>774 of the EAR and throughout the EAR. The
>Export Control Classification Number consists of
>a set of digits and a letter. Reference �738.2(c) of
>the EAR for a complete description of each
>ECCN's composition.
>"Object code". (or object language) (Cat 4)--An
>equipment executable form of a convenient
>expression of one or more processes ("source
>code" (or source language)) that has been
>converted by a programming system. (See also
>"source code")
>Foreign Terrorist Organizations (FTO). Any
>organization that is determined by the Secretary
>of the Treasury to be a foreign terrorist
>organization under notices or regulations issued
>by the Office of Foreign Assets Control (see 31
>CFR chapter V).
>
>D. Software
>! 5D002 Information Security - "Software".
>License Requirements
>Reason for Control: NS, AT, EI
>Control(s) Country Chart
>NS applies to entire entry NS Column 1
>AT applies to entire entry AT Column 1
>EI applies to encryption items transferred from the
>U.S. Munitions List to the Commerce Control List
>consistent with E.O. 13026 of November 15, 1996
>(61 FR 58767) and pursuant to the Presidential
>Memorandum of that date. Refer to �742.15 of the
>EAR.
>Note: Encryption software is controlled
>because of its functional capacity, and not
>because of any informational value of such
>software; such software is not accorded
>the same treatment under the EAR as other
>"software"; and for export licensing
>purposes, encryption software is treated
>under the EAR in the same manner as a
>commodity included in ECCN 5A002.
>License Exceptions for commodities are
>not applicable.
>Note: Encryption software controlled for
>EI reasons under this entry remains
>subject to the EAR even when made
>publicly available in accordance with part
>734 of the EAR, and it is not eligible for
>the General Software Note ("mass market"
>treatment under License Exception TSU
>for mass market software). After a
>technical review, certain encryption
>software may be released from EI controls
>and made eligible for the General Software
>Note treatment as well as other provisions
>of the EAR applicable to software. Refer
>to �742.15(b)(1) of the EAR, and
>Supplement No. 6 to part 742 of the EAR.
>License Exceptions
>CIV: N/A
>TSR: N/A
>! List of Items Controlled
>Unit: $ value
>Related Controls: See also 5D992. This entry
>does not control "software" "required" for the
>"use" of equipment excluded from control
>under to 5A002 or "software" providing any of
>the functions of equipment excluded from
>control under 5A002.
>Related Definitions: 5D002.a controls
>"software" designed or modified to use
>"cryptography" employing digital or analog
>techniques to ensure "information security".
>Items:
>a. "Software" specially designed or modified for
>the "development", "production" or "use" of
>equipment or "software" controlled by 5A002,
>5B002 or 5D002.
>b. "Software" specially designed or modified to
>support "technology" controlled by 5E002.
>c. Specific "software" as follows:
>c.1. "Software" having the characteristics, or
>performing or simulating the functions of the
>equipment controlled by 5A002 or 5B002;
>c.2. "Software" to certify "software"
>controlled by 5D002.c.1.
>a. "Software", as follows:
>a.1 "Software" specially designed or modified
>for the "development", "production", or "use" of
>telecommunications equipment containing
>encryption (e.g., equipment controlled by
>5A992.a);
>a.2. "Software" specially designed or modified
>for the "development", "production:, or "use" of
>information security or cryptologic equipment (e.g.,
>equipment controlled by 5A992.b);
>b. "Software", as follows:
>b.1. "Software" having the characteristics, or
>performing or simulating the functions of the
>equipment controlled by 5A992.a.
>b.2. "Software having the characteristics, or
>performing or simulating the functions of the
>equipment controlled by 5A992.b.
>c. "Software" designed or modified to protect
>against malicious computer damage, e.g., viruses.
>
> (9) Export of encryption source code and
>object code software.
>(i) For purposes of the EAR, the export of
>encryption source code and object code software
>means:
>(A) An actual shipment, transfer, or
>transmission out of the United States (see also
>paragraph (b)(9)(ii) of this section); or
>(B) A transfer of such software in the United
>States to an embassy or affiliate of a foreign
>country.
>(ii) The export of encryption source code and
>object code software controlled for EI reasons
>under ECCN 5D002 on the Commerce Control
>List (see Supplement No. 1 to part 774 of the
>EAR) includes downloading, or causing the
>downloading of, such software to locations
>(including electronic bulletin boards, Internet file
>transfer protocol, and World Wide Web sites)
>outside the U.S. (except Canada), or making such
>software available for transfer outside the United
>States (except Canada), over wire, cable, radio,
>electromagnetic, photo optical, photoelectric or
>other comparable communications facilities
>accessible to persons outside the United States
>(except Canada), including transfers from
>electronic bulletin boards, Internet file transfer
>protocol and World Wide Web sites, unless the
>person making the software available takes
>precautions adequate to prevent unauthorized
>transfer of such code outside the United States or
>Canada. Such precautions shall include ensuring
>that the facility from which the software is
>available controls the access to and transfers of
>such software through such measures as:
>(A) The access control system, either through
>automated means or human intervention, checks
>the address of every system requesting or
>receiving a transfer and verifies that such systems
>are located within the United States or Canada;
>(B) The access control system provides every
>requesting or receiving party with notice that the
>transfer includes or would include cryptographic
>software subject to export controls under the
>Export Administration Regulations, and that
>anyone receiving such a transfer cannot export the
>software without a license; and
>(C) Every party requesting or receiving a
>transfer of such software must acknowledge
>affirmatively that he or she understands that the
>cryptographic software is subject to export
>controls under the Export Administration
>Regulations and that anyone receiving the transfer
>cannot export the software without a license.
>BXA will consider acknowledgments in
>electronic form provided that they are adequate to
>assure legal undertakings similar to written
>acknowledgments.
>
>
>-- Perhaps we can discuss exactly what all this means after you all
>have read this.
>
>AS
It means that the whole AES project is Bogus. It means that people
from the US who go to conferences to even discuss enryption since
this is technical support are in voilation. And it most likely is
unconstitutuonal. But hey so is talking money from the Chinese military
but is Reno putting anyone on trail NO. She can't even find the thousands
of feet of film footage from Waco. She is pissed that maybe some one
in the FBI must not realizes that there main job is to protect what ever lies
she and president tell. It would not surprise me that if you sucked on your
mothers breast as a baby. There is most likey some fucking law that says
regardless of the woman if you every sucked on a female breast to the amount
of force to suck bodily fluilds from you it you are guilty of molesting a
woman and should be tried as an adult and go to jail.
So fucking what, I would like to know what the REAL law says not some
fucking regualtion that is supose to be be the imlamentation of the law
which any one can plainly see is unconstitutional.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Ed Stone)
Subject: Re: 512 bit number factored
Date: Mon, 30 Aug 1999 09:27:23 -0400
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> In the CryptoBytes for Summer of 1995, after Andrew Odlyzko's article on the
> future of Integer Factorization, I find on p. 12 a recomendation by RSA Labs on
> minimum RSA keysizes of 768 for user keys, short term security. In Andrew's
> article, he points out that 512 is already able to be attacked with existing
> equipment. I cannot find an earlier reference than this for setting a minimum
> RSA key size beyond 512 bits by RSA Labs. Perhaps someone can enlighten me,
> but this statement was made only 4 years ago.
> Don Johnson
"In this note we address the short-term security o ered by the use of a
512-bit RSA modulus. Following recent tremendous improvements to the
practicality of the generalized number eld sieve, it must be expected
that by the end of next year, a 512-bit RSA number will have been
factored. However, for those elded systems which use 512-bit RSA, what
are the implications? Some systems may well continue using 512-bit RSA
long after one particular 512-bit RSA number has been factored. In this
note, we present data which might provide answers to questions about the
continuing use of a 512-bit RSA modulus."
This is from
http://www.rsa.com/rsalabs/pubs/techreports/security_estimates.pdf and
lists in the References the following:
"[3] A. Odlyzko. The future of integer factorization.
4 CryptoBytes, 1(2), Summer
1995. To appear."
So the security estimate *may* predate Odlyzko's CryptoBytes article by a
few weeks or so...
>
--
--
=======================
Ed Stone
[EMAIL PROTECTED]
delete "-birdname" spam avoider
=======================
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: WT Shaw temporarily sidelined
Date: Tue, 31 Aug 1999 00:21:56 GMT
In article <7qee8e$cf$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (John Savard) wrote:
>> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote, in part:
>>
>> >I think he is in Texas
>> >is he not.
>>
>> Yes, I think so too. And I thought you were in New York or
>> thereabouts, so you probably wouldn't get the chance to just drop by.
>>
>> But I do wish him a speedy recovery.
>>
>> John Savard ( teneerf<- )
>> http://www.ecn.ab.ca/~jsavard/crypto.htm
>>
>This may be a dumb question, but what's wrong with him?
I hope he does not know to much info on Waco or it is
possible he could have a larger accident in the hosptial since
there may be a new wave in governemnet to destory any evidence
that could put Reno in a bad light.
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
