Cryptography-Digest Digest #71, Volume #11 Tue, 8 Feb 00 12:13:01 EST
Contents:
Re: Strip Security (Gordon Walker)
Re: Strip Security (Gordon Walker)
Re: How secure is this method? What about this? (Erik)
Re: Strip Security ("Tyler Beard")
Re: compression (John Savard)
Re: Hill Climbing (G Winstanley)
Re: Hill Climbing (G Winstanley)
Re: DVD crypt Q (mdc)
Re: Anti-crack (CJ)
Re: Message to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Student security columnist wanted for ACM Crossroads (Kevin E. Fu)
Re: Message to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Senior Thesis Assistance (John Savard)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Gordon Walker)
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Tue, 08 Feb 2000 14:16:41 GMT
On Tue, 08 Feb 2000 03:22:55 GMT, [EMAIL PROTECTED]
(Highdesertman) wrote:
>Gordon, this is a bit off topic, but I have a related question.
>
>I am wondering how you arrived at 10,000 possible combinations with a
>four digit pin. I don't doubt it is correct, I just would like to know
>what the formula is for determining how many possible combinations
>there are given any particular number of digits/letters.
For purely numeric keys the calculation is quite simple. It's simply
the range of values you can represent in the given number of digits.
Thus in four digits the smallest value is 0000 and the largest 9999.
This range emcompases 10000 intermediate values.
The more general case is based on the number of characters in the PIN
and the number of different symbols available for each character. For
example, a one character PIN where that character can be an upper-case
letter of the alphabet has 26 possible combinations. If you make that
a two character PIN then the first character can be any of 26 symbols
and the second can likewise be any of 26 symbols. How many
combinations in total? Cycle through each possibility in the first
character: for 'A' the second character may be 'A' or 'B' or 'C' etc.
In other words when the first character is 'A' there are 26
possibilities. When it is 'B' there are another 26 making 52. When it
is 'C' there are another 26 making a total of 78 and so on. In short
there are 26*26 combinations - 676. Add a third character and for each
of these 676 possibilities there are another 26. A three character PIN
thus has 17576, or 26*26*26, combinations.
If we allow both upper and lower case characters then the number of
possible symbols in each character jumps to 52. The total number of
combinations for three characters is thus 52*52*52=140608. If we allow
upper and lower case characters and numeric symbols we have 62
possible symbols and a total of 238328 combinations.
--
Gordon Walker
------------------------------
From: [EMAIL PROTECTED] (Gordon Walker)
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Tue, 08 Feb 2000 14:16:42 GMT
On Tue, 08 Feb 2000 04:58:49 GMT, [EMAIL PROTECTED] wrote:
>It's not my lost Palm I'm worried about for the reasons you list --
>it's the backup file in my Palm desktop.
>
>Combining a compromised computer on my office network with a network
>share "vacuum" (currently being discussed on the VULN-DEV list) leads
>to the possibility that the backup of my Strip database could be
>discovered by a canny intruder (or the script kiddie using the canny
>intruder's program). If I were a cracker, an admin's Strip
>database would be a juicy target.
For the reasons given below I'm not worried about anyone getting my
Strip database. However, because there is other non-encrypted personal
information, I keep my Palm directory on a PGP encrypted volume which
I only mount when I'm working with it.
>Just what is the average number of crypt calls and the time per call to
>brute force a 128-bit DES key?
A 128-bit value has a range of 0 to
340,000,000,000,000,000,000,000,000,000,000,000,000. That is 340
billion billion billion billion. If we assume that there are no flaws
in the IDEA algorithm that allow us to substantially reduce that value
then a brute force attack, trying one key after another until we find
the right one, will require us to look on average at half of this
range. That is, we must examine 170 billion billion billion billion
possible keys. If a super-computer running at 10 teraflops (10
thousand billion floating point operations per second) could analyse a
candidate in a single operation it would still take 600 million
billion millenia to complete.
No-one can brute force IDEA. No-one can come close. The one avenue of
attack is the as-yet theoretical quantum computer. But no-one has
built one yet. At least, we don't think so ...
--
Gordon Walker
------------------------------
From: Erik <[EMAIL PROTECTED]>
Subject: Re: How secure is this method? What about this?
Date: Tue, 08 Feb 2000 09:25:26 -0500
Sandy Harris wrote:
> >If not, what's a better pseudo-random number algorithm? Thanks.
>
> Schneier's "Applied Cryptography" discusses stream cipher design in
> some detail. Look there.
Thanks, I picked up the book and I'll use one of the stream ciphers he
shows there.
> >and is the linear congruence algorithm sufficient for this purpose?
>
> Absolutely not, even if you combine outputs from several of them.
>
Just for the sake of argument, what if you seed two such PRNGs (A & B),
then
1) Get a number from A, Na, from 1 to 32,
2) Get a number from B, Nb, which is Na bits long.
3) XOR the next Na bits of plaintext with Nb.
and repeat
To me it seems difficult for an attacker to determine the output of the
PRNGs or the seeds, even if he knew a large chunk of the plaintext.
There are too many possibilities for where a number might start or end.
Am I wrong?
Erik
------------------------------
From: "Tyler Beard" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Mon, 7 Feb 2000 23:47:14 -0600
Mathew,
To determine the number of possible combinations of PIN's is just like
determining the possible combinations of a combination lock, and for
illustrative purposes easier (I think) to understand. So, imagine a
combination lock like the ones used for briefcases and some bike locks.
Imagine this lock to have only one digit wheel. With such a scenario there
would be 10 possible combinations. Now imagine two digit wheels. For each
digit on the first wheel, we can now have 10 different second digits. This
obviously continues for each digit on the first wheel, thus, 10 digits of
the first wheel X 10 digits of the second, i.e. 100 combinations. Likewise
with three wheels 10x10x10 or 10^3. And now to your question, four wheels
would result in 10^4 possible combinations, or 10,000.
The solution is just as simple for alpha-numeric codes, only the number of
unique choices for each "wheel" increases from 10 to 36 (10 numerals + 26
letters). Thus the calculation changes from 10^(number of wheels), to
36^(number of wheels). So the number of unique combinations for a 6
character alpha-numeric password is 36^6, or 2,176,782,336.
Hope this helps, and pardon the intrusion into your question to Gordon. (As
a math/science teacher I couldn't resist. Though please note that I am by
no means a encryption expert.)
Tyler
Highdesertman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Gordon, this is a bit off topic, but I have a related question.
>
> I am wondering how you arrived at 10,000 possible combinations with a
> four digit pin. I don't doubt it is correct, I just would like to know
> what the formula is for determining how many possible combinations
> there are given any particular number of digits/letters. Say for
> instance, we are dealing with a 6 digit numerical pin. If we know they
> are numbers, then it should be fairly straightforward to determine
> mathematically how many possible combinations are available as opposed
> to a three digit pin. What is the method of determining this, and what
> must be taken into account for more complex systems that include alpha
> numeric placeholders. Also, exponentially, how do the combinations
> increase with each additional digit?
>
> copy sent to sci.crypt.
>
> cheers,
>
> Mathew
>
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: compression
Date: Tue, 08 Feb 2000 08:38:23 GMT
[EMAIL PROTECTED] wrote, in part:
>hello
>I have been working my way through a book to learn cryptography one of
>the exercises i cannot answer any help would be greatly appreciated, it
>is as follows:
>A -> B : E_K(m � h (m))
>why does putting more bits into k than h(m) foil an attacker?
Putting more bits into k than in the total of m and h(m) would foil an
attacker for some forms of encipherment, on the principle of a
one-time-pad.
So, if m is inherently random, having no reduncancy of its own, then
h(m) contains the only redundancy in the concatenation of m and h(m).
In that case, if a key used to encipher only one message has more bits
than h(m), a brute-force search will turn up more than one message
with a valid hash attached to it.
>Why shoild messages be compressed before being encrypted?
Redundancy is reduced.
>Should just the hash of a message be encryped or the hash and the
>message?
If you only encrypt the hash, people can read your message. If only
authentication is desired, I am not sure about how it matters which
one is done.
>How can B convince C, KDC, that the message is from a? Is this a good
>idea?
If C knows A sent the encrypted message, give C the key, and since it
decodes to have a valid hash, the key was presumably the right key, so
C can be convinced the plaintext version of the message is the correct
one.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: G Winstanley <[EMAIL PROTECTED]>
Subject: Re: Hill Climbing
Date: Tue, 08 Feb 2000 15:50:02 +0000
Reply-To: [EMAIL PROTECTED]
On Mon, 07 Feb 2000 22:01:45 GMT, the cup of "Douglas A. Gwyn"
<[EMAIL PROTECTED]> overfloweth with the following:
> G Winstanley wrote:
> > As far as scoring goes...Incidence of Coincidence has proven not very
> > effective in my Playfair solving, and I finally went with trigraph
> > frequencies.
>
> The main trick is for the scoring function to give "part credit"
> when one has a "partial solution". Trigraph frequencies work in
> this case because they span multiple encryption units.
Precisely :-)
Hence I used them. Interestingly, I couldn't get it to converge nearly as
fast when using tetragraph frequencies. I understand that with digraph
frequencies you will get false positives due to the digraph nature of the
cipher; does this somehow carry over to tetragraphs?
Stan
------------------------------
From: G Winstanley <[EMAIL PROTECTED]>
Subject: Re: Hill Climbing
Date: Tue, 08 Feb 2000 15:50:04 +0000
Reply-To: [EMAIL PROTECTED]
On Tue, 8 Feb 2000 09:14:56 -0000, the cup of "Michael Darling"
<[EMAIL PROTECTED]> overfloweth with the following:
> After reading the Mark VandeWettering post on the CypherChallenge I've built
> myself a Trigraph Frequency Dictionary
> and I am going to attempt his 5000 squares method.
>
> He doesn't really mention how to mutate his chosen squares so I'm just going
> to do random swapping of letters to
> begin with, and see how that goes.
>
I also found this and asked Mark directly about his approach. What's really
needed is just a good spread of "mutations" (it seems). What can happen in a
Playfair grid?
No mutation
Single letter swaps
Row/row or column/column swaps
Row/column swap
Row/row or column/column inversions
Totally new grid
etc.
The difficult part is deciding what ratios to assign each of these mutations
to the children. The highest percentage in mine left the grid well alone,
and the others were held around 5%. The hill-climbing algorithm was also
treated as a type of mutation which happened about 0.01% of the time (rather
more often that Mark suggested). It slows down the mutation cycle
*enormously*, but also provides the quickest convergence.
To be honest I think of my program as primarily a hill-climber, which the GA
simply providing a good random starting point selection. Once I finally had
it working in the way I had anticipated it found the "almost solution" after
16 generations. A small amount of hand tweaking of the grid then solved it
properly. Only a few letters were bad in the plaintext anyway, so it could
be read without a problem.
Stan
------------------------------
From: [EMAIL PROTECTED] (mdc)
Crossposted-To: rec.video.dvd.tech
Subject: Re: DVD crypt Q
Date: Tue, 08 Feb 2000 16:02:19 GMT
Since the release of the deCSS crack, DVD encryption has gotten
a lot of discussion. I'm not an expert on it so I can't answer your
questions point by point, but there should be a lot of documentation
available on the net.
Goto http://www.slashdot.org/
and do a search for CSS. Their discussions on the topic have
included pointers to many resourcses.
Also, http://cryptome.org/
has a "speech" (as in free speech not source code) version of
deCSS that they claim is not covered by the various injunctions
against distributing deCSS. Since it handles decryption of DVDs,
it might answer many of your questions.
mdc
On 8 Feb 2000 09:02:32 GMT, Stephen Lee - Post replies please
<[EMAIL PROTECTED]> wrote:
>I have a question about the crypto used on DVD. I have read articles
>on the web but there are some points not clear to me. This is
>regarding a PC/Mac with a DVD-ROM connected.
>
>From <http://www.dvddemystified.com/dvdfaq.html>:
>
> On the computer side, DVD decoder hardware and software must
> include a CSS decryption module. All DVD-ROM drives have extra
> firmware to exchange authentication and decryption keys with the
> CSS module in the computer.
>
>1) I understand DVDs use the UDF filesystem. Is a Video DVD just a
>DVD-ROM with specific files on it?
>
>2) Why is authentication neccessary? I remember (maybe wrong)
>someone mentioning that some part of a DVD is not readable until the
>user authenticate with the drive. Is this true?
>
>3) Why would the DVD-ROM need decryption key when decryption is done
>by separate hardware/software? Maybe I am misunderstanding, but if
>decryption is done by the drive, then wouldn't something like DeCSS be
>unneccessary?
>
>4) I also read that DVD-Video Disc has some special part that stores
>the decryption keys and this part is blanked on recordable DVDs.
>
>4a) Is this true?
>4b) Why does the Disc need to have the key? I thought the player has
>1 key and the Disc has its content scrambled (encrypted?) by ~400 keys?
>
>5) Where does regional code come into the picture? Where is the
>regional code stored on a disc and how is it checked? I heard newer
>DVD-ROMs has the check built in, does it mean that older drives
>hasn't and it is checked somewhere else?
>
>That's all I can think of for now. I am very confused. Please help
>me clear this up.
>
>Thanks,
>Stephen
>
>
------------------------------
From: [EMAIL PROTECTED] (CJ)
Subject: Re: Anti-crack
Date: Tue, 08 Feb 2000 16:03:03 GMT
I was actually thinking in terms of that since DLLs can be shared by
many processes they have to exist in a separate address space.
But I checked it, and it seems every process gets a copy of a shared
DLL.
>The Windows marketing machine has gotten to you. All that hype about
>separate address space and the like is really an awful lie.
>
Apparently you didn't read my message, I said there are probably tools
which can trace DLLs, and for the latter issue I proposed encrypting
the DLL on disk and create it in RAM on the fly. According to a FAQ
this is possible with CoCreateObject. (However not useful if you
can't protect that DLL in RAM.)
>
>Our AXcrak product, for example, as well as our QB99crak and QW99crak
>software grab a process by the short hairs and bypass the password
>protection and encryption built into the target process.
>http://www.crak.com This works even if the security parameters are set quite
>high because certain access has to be granted to the user of a process if
>the process is going to be of any use to the user.
>
>The fact that dll's are used is not relevant. Anyone familiar with the
>Windows API can grab any subroutine in a DLL and use it by function name or
>ordinal number. These are easily discovered if one has access to a good
>file viewer or disassembler.
>
>JK http://www.crak.com
>
>
>CJ <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Mon, 07 Feb 2000 16:04:41 -0500, Arthur Dardia <[EMAIL PROTECTED]>
>> wrote:
>>
>> >CJ wrote:
>> >
>> >> Has anyone researched means of protecting
>> >> programs from being cracked with encryption?
>> >>
>> >> I'm not an expert in either area, but what I understand
>> >> of cracking is that ultimately you are looking for the
>> >> machine instruction in the executable which compares
>> >> password/serial number etc. to some given
>> >> value.
>> >>
>> >> So I was thinking one could maybe encrypt this piece
>> >> of the executable and decrypt on the fly when the application
>> >> starts. You might be able to trace the decryption and try to
>> >> spot the key used, but that would be more difficult (esp.
>> >> as you wouldn't know what algorithm is used).
>> >>
>> >> I'm not sure one can prevent direct tracing of the executable
>> >> code once it has been decrypted however. (I was thinking
>> >> maybe having it in a DLL, but this is maybe traceable too.)
>> >> Are there any better ways?
>> >
>> >Rather than tracing through the encryption/decryption routine, the
>> >cracker could just write a jump command. At some point you're going to
>> >have to try the key against the the encrypted serial number. By tracing
>> >through the dissassembled code, the cracker will be able to see the
>> >routine you used, he can then write a keygen using one of the engines by
>> >taking your encryption code directly from the dissassembly file.
>> >
>> Yes, I was assuming you can have some area of RAM which isn't
>> traceable. As far as I understand DLL files are not part of the main
>> program, they exist in a separate memory space and the main program
>> only calls their external functions (this is also how Windows
>> programming is done). So I don't think it would be as simple as a jump
>> in the main program in this case, but I believe there are tools which
>> can trace into them.
>>
>>
>> >To sum it up, every program is crackable, it'll just take time, which
>> >isn't a factor, because you still won't get the registration money, and
>> >he'll then just want to share the wealth of his efforts with more people
>> >(bragging for completing a tough crack).
>> >
>> >--
>> When thinking about shareware, one could try to abandon the basic if
>> x=y then ok else structure and try something else. For instance the
>> serial number might be the key used to decrypt the program instead of
>> being compared to something. One serial/key might decrypt it to a
>> trial version and another to a full version. I haven't thought this
>> through however.
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Tue, 08 Feb 2000 16:15:28 GMT
Well I definetly sent two emails to your email address...God knows where
they went....maybe u got a vacum cleaner sitting on your isp... :-)
Your post....went somthing like this:
You said you needed 3 ciphers and 2 one to one compressions which
can be done in one pass over all the file or five passes.
Pass one encrypt with an "AES" ciper
Pass two use Compression A
Pass three encrypt with a different key or different cipher
Pass four use Compression B
Pass five encrypt with a different Key
Perhaps you can explain how that works...
Why not just do a single compression followed by
an AES encyption...why 3 encrypts and 2 compressions...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Student security columnist wanted for ACM Crossroads
From: [EMAIL PROTECTED] (Kevin E. Fu)
Date: 08 Feb 2000 16:33:07 GMT
Hi all,
If you're a student interested in writing about security, please read
the announcement below. Unlike editorial board positions, this
position requires only that you focus on the topic of security. You
won't have to do any administration of the magazine itself.
You need not have expertise in all the areas below, but it would be
useful to have expertise in a few and knowledge in many.
-Kevin Fu
ACM Crossroads
General Editor
ACM Crossroads has decided to start a monthly column, focused on
computer and network security. We're looking for someone to write
this column. If you have expertise in many of the following areas,
we'd love to hear from you. Applicants must be students for the
entire time that they write the column, and we will give preference to
those applicants who will be in school long enough to write 12 columns
(one year's worth). Additionally, we prefer students who are members
of the ACM, but this is not absolutely required.
The details of the column would be something like this: The four
columns that coincide with the publication of a print issue will be
printed. These four columns must not exceed 800 words. The eight
remaining columns will be published online and thus have no page
limitations.
Areas of interest for column topics:
* Secure email
* Intrusion detection
* Anonymous mailers
* Applied cryptography
* Encryption technology
* Public key cryptography
* Digital signatures
* Firewalls
* Viruses, worms, and related beasts
* Key management
* Certificates
* Public key infrastructure
* Secure Protocols
* Biometrics
* etc.
To apply to be the writer of this monthly online column, send an email
to [EMAIL PROTECTED] and include:
1) Information about yourself: Name, Where you go to school, What major
you are in, Your expected graduation date.
2) Qualifications: Why do you think you are qualified to write this
column? Include any references to your publications, coursework, or
work experience.
3) A list of 12 topics (one each month) that you would cover if you
are chosen.
4) A sample column, in HTML, no more than 800 words.
Incomplete applications will not be considered. We will begin
evaluating applicants on February 15, 2000, and notify you by the end
of February 2000.
About Crossroads: ACM Crossroads is the student magazine of the
Association for Computing Machinery. Crossroads is printed
quarterly, with a subscription base of nearly 20,000 students. In
addition, the full content of Crossroads is available online.
For more information about Crossroads, please see
www.acm.org/crossroads/doc/information/
--
Kevin E. Fu ([EMAIL PROTECTED])
PGP key: https://snafu.fooworld.org/~fubob/pgp.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Tue, 08 Feb 2000 16:28:43 GMT
In article <87p6sm$27a4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <87n8rr$3d2$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> >Hi...
......SNIP.......
> so that the NSA can still be kept reading your email. By the way I
wrote the
> government batards a month ago and they never anwsered my email since
I
> would like to post encyption code at my site. Has anyone had any luck
with
> the bastrads.
>
If you didn't get a reply means they didn't get the message! :)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Senior Thesis Assistance
Date: Tue, 08 Feb 2000 09:36:18 GMT
Christopher MacPherson <[EMAIL PROTECTED]> wrote, in part:
>Right now I am planning on doing a study on attack methods. My plan is
>to take an algorithm with a known attack, demonstrate the attack, and
>then attempt to make the algorithm unbreakable.
>Does anyone have any suggestions for an algorithm (and attack) that fits
>this criteria? I will be able to get time on a super computer should I
>need one to execute the attack.
The main problem with this is that you can demonstrate easily that the
changed algorithm can't be broken with the computer program you used
the first time. Showing that the attack couldn't be modified easily to
overcome the change you've made (of course, proving a completely new
attack is not possible is impossible) is something that requires
theoretical work.
One could demonstrate a differential cryptanalysis attack on LUCIFER,
or a linear cryptanalysis attack on DES, and then stick in an extra
stage with a key-dependent S-box that indeed would kill such attacks
and related ones dead...but that's sufficiently trivial as not to be
worth using supercomputer time on, never mind trying it as a thesis
project.
One of the rejected AES candidates, LOKI 97, had a weakness due to
bias in the S-boxes. Looking at that attack, and making the
modifications required to defeat it (think of the DES S-boxes, and
which input bits to the S-box are normal and which are supplementary,
which should, in the case of LOKI 97, pick a permutation of the byte
values 0-255) might be something on the scale of what you're looking
for. But I think you'll need to look for something a bit more
challenging.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 8 Feb 2000 16:59:41 GMT
r.e.s. <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote ...
: : : Note that if the answer to the second question is yes (all Latin
: : : Squares are in PRT-form), then we can reduce any Latin Square of
: : : order N to three arrays of N entries, which means that the internal
: : : state of a square of order N is bounded by 3N, not by N^2. (Right?)
: :
: : The information content is smaller than this perhaps might suggest - since
: : each array entry is itself constrained.
: :
: : N! x N! x N! - for the Latin Square - compared to N^(N^2) for the totally
: : random table. ^^^^^^^
: But the table can't be totally random if it's to be a workable
: combiner. [...]
Indeed not. Only a tiny fraction of these would be valid Latin squares.
: So I think that that latter number should be N!^N instead of N^(N^2).
That is /an/ upper bound. It may be possible to do much better, though.
N!^(N-1) is a smaller bound - since if N-1 columns are known, the last
column is uniquely determined.
I have a figure of 161820 possible 5x5 latin squares. This doesn't
conform to the N!^N formula very well at all (though it's the right side
of it when taken as a bound).
The last I heard, the function yielding the number of Latin squares of
size NxN was one of the unsolved problems of mathematics - since no
simple expression of it has yet been discovered.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Breast is best.
------------------------------
** 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
******************************
