Cryptography-Digest Digest #482, Volume #11 Tue, 4 Apr 00 03:13:01 EDT
Contents:
Re: new Echelon article ([EMAIL PROTECTED])
Re: Simple authentication protocol: any good? ("Joseph Ashwood")
Re: TEA? ("Simon Johnson")
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...) ("anonymous")
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Joseph Ashwood")
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Joseph Ashwood")
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: Examples of topology related to crypto ? (Klaus Pommerening)
Re: summing hashes is not safe? (David Hopwood)
Re: GSM A5/1 Encryption (Gregory G Rose)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,talk.politics.crypto,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Tue, 04 Apr 2000 04:45:42 GMT
On Sat, 18 Mar 2000 20:28:20 GMT, [EMAIL PROTECTED] (JimD)
wrote:
>On Sat, 18 Mar 2000 15:01:58 GMT, [EMAIL PROTECTED] wrote:
>
>>On Sat, 18 Mar 2000 09:33:08 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
>>wrote:
>>
>>>Jos Horikx wrote:
>>>> Another interesting echelon-article on:
>>>> http://cryptome.org/echelon-cia2.htm
>>>
>>>Thanks; that was a refreshing change from Duncan-Campbellism.
>>
>>Made even more interesting in that Mr. Woolsey is defending himself
>>and his methods of industrial espionage against accusations not yet
>>cast.
>>
>>Mr. Woolsey claims in that Wall Street Journal opinion that the EU
>>report accuses the CIA/NSA of using Echelon to steal technology from
>>non-U.S. companies. While I don't doubt that technology theft occurs,
>>the report by Duncan Campbell -- from my reading of it -- concerned
>>itself with asserting the U.S. might be using this eavesdropping
>>network to help specific companies _win contracts_.
>
>Well of course they do! Isn't '...the economic well-being of the
>United States.' part of the NSA's mission statement?
>
>They ALL do it...Britain, France, Germany, Israel, Russia, China...
>New focus to justify their existence post Cold-War, and it helps
>to maintain the funding.
>
>--
>Jim Dunnett.
>dynastic at cwcom.net
>Exiled in Somerset
>Right at the heart of England's BSE Industry.
Again, as I've noted, I haven't read the NSA's mission statement. But
... in the U.S., we have this thing called a Constitution, and the 5th
Amendment to the thing states:
"No person shall be held to answer for a capital, or otherwise
infamous crime, unless on a presentment or indictment of a grand jury,
except in cases arising in the land or naval forces, or in the
militia, when in actual service in time of war or public danger; nor
shall any person be subject for the same offense to be twice put in
jeopardy of life or limb; nor shall be compelled in any criminal case
to be a witness against himself, nor be deprived of life, liberty, or
property, without due process of law; nor shall private property be
taken for public use, without just compensation."
The pertinent section here is "No person shall be ... deprived of
life, liberty, or property, without due process of law."
If the CIA/NSA are assisting specific U.S. corporations win contracts
overseas, as it appears they are via Commerce/SBA/State Depts., et al,
(or assisting those corporations obtain specific technology), they are
depriving other U.S. persons who work for competing companies of
property by preventing those persons and their companies from winning
the contracts themselves.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Simple authentication protocol: any good?
Date: Mon, 3 Apr 2000 22:29:16 -0000
Basically your entire security depends on f(), if f() takes
a password and is one-way, and the passwords cannot be
searched, then it is possible to offer security that way.
Trully having all of these is difficult, see Kerberos for a
rather good example of just such work that is secure. An
additional problem is that you say you will be using linear
congruentials for random numbers, not the best idea, a much
better idea would be to go with something like Yarrow
(http://www.counterpane.com/yarrow.html), or /dev/urandom
(?) on Linux, they provide much better pseudo random
numbers. Because of the difficulty in creating a good
security situation, I'd actually suggest a well tested
canned method, SRP is just one of those
(http://srp.stanford.edu/srp/). The basic protocol is (all
computation is done modulus a big number N):
1. Carol send her username to Steve (e.g. Carol)
2. Steve looks up Carol's password entry and fetches her
password verifier v and her salt s. He sends s to Carol.
Carol computes her long�term private key x using s and her
real password P .
3. Carol generates a random number a, 1 < a < n, computes
her ephemeral public key A = g^a , and sends it to Steve.
4. Steve generates his own random number b, 1 < b < n,
computes his ephemeral public key B = v + g^b, and sends it
back to Carol, along with the randomly generated parameter
u.
5. Carol and Steve compute the common exponential value S =
g^(ab+bux) using the values available to each of them. If
Carol's password P entered in Step 2 matches the one she
originally used to generate v, then both values of S will
match.
S = (B-g^x)^(a+ux)
S = (Av^u)^b
6. Both sides hash the exponential S into a
cryptographically strong session key (K).
7. Carol sends Steve M1 as evidence that she has the correct
session key. Steve computes M1 himself and verifies that it
matches what Carol sent him. M1 = hash(A,B,K).
8. Steve sends Carol M2 as evidence that he also has the
correct session key. Carol also verifies M2 herself,
accepting only if it matches Steve's value. M2 =
hash(A,M1,K).
Joe
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: TEA?
Date: Tue, 4 Apr 2000 06:56:55 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Simon Johnson wrote:
> >
> > Would a modified version of TEA, using a 16-bit block, and 32-bit key,be
> > proportionally as strong as its 64-bit block, 128-bit key counterpart?
> >
> > Secondly, Is the addition mod 2^32 in TEA?
>
> Well no, cuz a 32 bit key is 2^96 times easier to solve, so it's not
> proportional based on size [well it's exponential]. And it would be
> easy to attack such a variant.
>
> And yes the addition is taken modulo 2^32.
>
> Tom
Thanxs, I let me rephrase my question. Does the linar & differenential
cryptoanayalsis strength remain the same if this modified version?
Background: I'm going to use RC4 to generate a stream- key, and then use TEA
as the main block-cipher. I'm betting on the fact the each pair of
characters, in my proposed weaking, would have to be brute-forced to recover
the text.
------------------------------
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who
is trying to silence our program? It's not working...)
From: "anonymous" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: Tue, 4 Apr 2000 05:51:37 GMT
yeah, I keep phosphorous flares handy myself. Just like the US gov embassies.
On 3-Apr-2000, Tom St Denis <[EMAIL PROTECTED]> wrote:
> BTW burning the hard disk at 1000c is still much more effective then any
> software :-)
>
> Tom
______________________________________________________________
Posted via Uncensored-News.Com, http://www.uncensored-news.com
Only $8.95 A Month, - The Worlds Uncensored News Source
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Mon, 3 Apr 2000 22:58:12 -0000
Crossposted-To: talk.politics.crypto
> As you may be aware, there is an extremely large key space
> available with OAP-L3.
Ummm, DUH, there a phenomenally huge key space available to
EVERY encryption algorithm, it's not the size that matters,
it's how you use it.
> Adding a few more processes is
> tantamount to approximately doubling the "through put"
> to this very large key space.
More proof that you have absolutely no clue what you are
talking about. Throughput is a matter of how fast the
"method(s)" is/are. By adding more "methods" without using
them to optimise the others you will DECREASE the
throughput, 100% of the time.
> It does make determining
> the key phenomenally that much more difficult.
Without revealing what the "methods" are that can be stated
but not verified. I have given an example of a function pair
that gives exactly the opposite, you have yet to show that
your functions behave in any other way.
> No one
> has to use them. They are simply made available. Their
use
> is up to the user. And my position remains the same.
You position being of course that every member of this group
is an idiot, your position has been disproven many times,
and only seems to indicate that you are in fact the one
lowering the amount of intelligence in this newsgroup.
>
> Address the software theory and processes and procedures
with
> factual support. Are you not up to it?
We have addressed your theory, you have not given enough
detail to make analysis reasonable. In spite of this at
least one person claims to have an attack, an attack that
you have repeatedly declined to make a statement on.
>
> You should spend more time devising your own encryption
method
> and impress us with that. You are not very convincing
telling
> me of what I should do.
Many of us have designed our own encryption methods. I for
example am working on one right now, it may or may not see
the light of day, depending on whether or not I can attack
it. You have done the opposite, your claim amounts to
"Lookie pretty letters, you can't you break it," this claim
has been made repeatedly in spite of the preponderence of
evidence.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Mon, 3 Apr 2000 22:59:05 -0000
Crossposted-To: talk.politics.crypto
> What Mr. Huuskonen is saying is that you should put it to
rest.
> My suggestion is acceptable to him.
I actually understood his reasoning in a different way, I
shouldn't have to tell you what it is, so I won't.
Joe
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Mon, 03 Apr 2000 23:09:46 -0700
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >I'll ask you again: how many raw random digits from the random
> >digit generator will you need? I will supply them. You can
> >then give us what you have determined to be the subsequent
> >raw random digits from the random digit generator.
>
> >Then I will provide the key for the software where we all can see
> >that the random digits I gave you were in fact the ones generated
> >from the software using this key.
>
> OK, fine - no BS, just the facts. However, I have trouble handling
> very large files (I'd need a couple hundred million digits for
> predicting the entire output stream), so I propose the following:
>
> You supply twenty blocks of a thousand consecutive digits each.
> Between each block and the next, the "Rotation" is incremented by 10,
> and the "Offset" is reset to zero. In other words, the starting digits
> of two consecutive blocks are 10! * 10 places apart in the full output
> stream of the random digit generator. You may start with any value for
> the Rotation that you want; just make it known afterwards.
>
> You can make the digits available in any reasonable format: ASCII or
> BCD, all the blocks concatenated in one large file or 20 small files,
> zipped or not, made available by HTTP or FTP, or e-mailed to me.
>
> I will make a thousand predictions of this form: "The digit at Rotation
> 234, Offset 43 is 5." If you can find one incorrect prediction, I've
> failed. So, my chances of succeeding by chance are 1 out of 10^1000.
>
> Deal?
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOOjmAV+t0CYLfLaVEQJQHgCdGjNvXKyM32E4mP8dW74Q8i7YPDQAn0rD
> 1Q6v3/9KiZOajAl/3FjT9CKU
> =DbCx
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
You certainly realize that there is at least one person in this
news group that actually thinks that the random digits from the
random digit generator are used directly in the encryption
process. This is because he hasn't a clue.
There may even be some in this news group that think that the
random numbers from 000 - 255 calculated directly from the random
number generator are used directly in the encryption process.
These people also haven't a clue.
For any who need a lesson: first a random digit triplet is formed
directly from the random digit generator. If this number is
greater than 767 it is discarded. Otherwise this number is
divided by 3 and the remainder is truncated. This and all
subsequent random numbers from 000 - 255 calculated in this manner
are then stored in RandOut files usually having a length of
18144000 binary bytes each. These several RandOut files are
further processed repeatedly using as many as ten different
processes. All processes use true random user input as parameters.
Finally, these RandOut files are combined randomly in the OTPs again
using true random user input. This is it in a nutshell. Read the
documentation available in the Help Files for more details at
http://www.ciphile.com
Let's now discuss your proposition strictly regarding the random
digit generator (this is not a discussion about the OAP-L3 software
as a whole.)
First let me say this: everyone knows that computer software
programs are entirely deterministic. Knowing the algorithm and
the inputs you can predict the output before even running the
process if you are so inclined. You can also go the other way.
Regarding encryption software I like to think of there being an
explicit key and an implicit key. It all depends on your point
of view.
The explicit key is the key I will use to create the three MixFiles
that I will use as input to the OAP-L3 random digit generator
software. Then I will generate the random digit streams you seek.
The implicit key is what you will be forced to use. This key is
the raw random digit output from the random digit generator.
Theoretically you may be able to determine the original MixFiles I
actually used. The more raw random digit output you have the more
possible this becomes: perhaps a few hundred million (I doubt it)
or a few hundred billion (possibly) or a few trillion (probably)
raw random digits in sequence directly from the start of the random
digit generator might do it exactly.
Suppose I do this: I will give you 21 consecutive blocks of
3,628,800 digits. The software automatically will rotate and
reset the increment to zero after each block. You just choose
the first 1000 or 10,000 or 100,000, etc. digits as you like
from each file. You can even check your results from the first
20 blocks with block 21. I will write these to a CD-R and mail
it to you.
At my option I would like three tests: this being the first.
Just give me any address you like. I will try to get it in the
mail to you within a week. Keep in mind that I am very busy
trying to get this next OAP-L3 Version 4.3 out.
Now, let us take a brief moment to think about your statement
that there is a flaw in the random digit generator. You choose
to call it a flaw. Think about this: we all know that computer
software is deterministic. By analysis of the process and with
enough output, anyone can determine subsequent output because
you will have effectively determined the MixFiles. So you have
done nothing but confirmed what we already had known (or should
have known.)
Next, you must agree, that the only way to exploit this fact is
to have basically unlimited access to the raw random digit output
of the random digit generator. How is anyone going to get this in
a real life situation except like I am giving it to you now? If
you could get the raw random digit output from the random digit
generator you would certainly have access to the MixFiles or better
yet, the AutoFile key itself. And possibly the final OTPs.
So what are you proving that is detrimental to the security of the
OAP-L3 system? You are merely solving a problem in simultaneous
equations, or solving multiple equations with sufficient numbers
of constraints (the raw random output from the random number
generator.)
You could not do this unless I gave you the raw random digit output
of the random digit generator in the first place. Are you next
going to say that you can crack OAP-L3 encrypted messages if I
give you the OTPs and then conclude that you have proven your
statement and therefore OAP-L3 is flawed? Basically this is what
you are saying and attempting to convince others of with this
inconsequential "test."
So, if you do manage to predict a few or all the random digits
subsequent to the random digit stream I provide you with, so what?
You will have shown us nothing that anyone can use to crack the
software or any of the encrypted messages using OAP-L3.
Do you disagree? Why? How?
I do agree that you can at least show your employer that you have
done something in the hopes of justifying your salary but
unfortunately you have gotten no further to the goal of cracking
the OAP-L3 software.
Post the address.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Mon, 03 Apr 2000 23:16:38 -0700
Joseph Ashwood wrote:
>
> > As you may be aware, there is an extremely large key space
> > available with OAP-L3.
>
> Ummm, DUH, there a phenomenally huge key space available to
> EVERY encryption algorithm, it's not the size that matters,
> it's how you use it.
>
> > Adding a few more processes is
> > tantamount to approximately doubling the "through put"
> > to this very large key space.
>
> More proof that you have absolutely no clue what you are
> talking about. Throughput is a matter of how fast the
> "method(s)" is/are. By adding more "methods" without using
> them to optimise the others you will DECREASE the
> throughput, 100% of the time.
>
> > It does make determining
> > the key phenomenally that much more difficult.
>
> Without revealing what the "methods" are that can be stated
> but not verified. I have given an example of a function pair
> that gives exactly the opposite, you have yet to show that
> your functions behave in any other way.
>
> > No one
> > has to use them. They are simply made available. Their
> use
> > is up to the user. And my position remains the same.
>
> You position being of course that every member of this group
> is an idiot, your position has been disproven many times,
> and only seems to indicate that you are in fact the one
> lowering the amount of intelligence in this newsgroup.
>
> >
> > Address the software theory and processes and procedures
> with
> > factual support. Are you not up to it?
>
> We have addressed your theory, you have not given enough
> detail to make analysis reasonable. In spite of this at
> least one person claims to have an attack, an attack that
> you have repeatedly declined to make a statement on.
>
> >
> > You should spend more time devising your own encryption
> method
> > and impress us with that. You are not very convincing
> telling
> > me of what I should do.
>
> Many of us have designed our own encryption methods. I for
> example am working on one right now, it may or may not see
> the light of day, depending on whether or not I can attack
> it. You have done the opposite, your claim amounts to
> "Lookie pretty letters, you can't you break it," this claim
> has been made repeatedly in spite of the preponderence of
> evidence.
> Joe
I really get to you: don't I?
Yes, through put is an accurate description. You see, with the
original selection of methods it might take hundreds or thousands
or millions or more executions of these existing processes to
locate the final MixFiles within a particular area within the
key space. But the user may be able to get to this same general
area using a selection of these new methods only a few tens of
times. This would seem like in big increase in speed in getting
from point A to point B.
Give us some substance and quit trying to convince us that you
are in the running for the Olympic crying team.
------------------------------
From: [EMAIL PROTECTED] (Klaus Pommerening)
Crossposted-To: sci.math
Subject: Re: Examples of topology related to crypto ?
Date: 4 Apr 2000 06:47:24 GMT
In <8c5l6h$7lu$[EMAIL PROTECTED]> [EMAIL PROTECTED] wrote:
> ..., refers to a seemingly interesting theorem by
> Beutelspacher & Rosenbaum which I have never heard of:
> http://www.mirageonline.it/zanella/
>
I once heard a talk by Stephan Schmidt of AT&T research where
he used the Zariski topology of schemes over finite rings for
modelling complex secret sharing schemes. But this is also
rather finite geometry and combinatorics, as is Beutelspacher's
work.
After all, topology is mainly about nondiscrete phenomena
whereas cryptology is a `discrete' subject. Therefore
substantial applications of topology to cryptology seem
rather unlikely.
--
Klaus Pommerening [http://www.Uni-Mainz.DE/~pommeren/]
Institut fuer Medizinische Statistik und Dokumentation
der Johannes-Gutenberg-Universitaet, D-55101 Mainz, Germany
------------------------------
Date: Tue, 04 Apr 2000 04:34:43 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: summing hashes is not safe?
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> Just came across some code in which multiple (100's) 20 byte message-
> digests are summed into one 24 byte sum as a hash for the complete
> batch.
> Something tells me this is not the way to handle (SHA-1) hashes. Can
> anyone confirm my feeling that it's fairly easy to add fake messages?
If the purpose is to create a hash of a set of messages independent of
ordering, this is not at all as bad as it sounds (actually XOR would
do just as well as addition). It requires a fairly strong assumption
on the "pseudo-randomness" of the hash output, but for SHA-1 it would
probably be OK. In particular, if the hash acts an ideal PRF, it seems
not to be breakable (for collision-, pre-image and 2nd pre-image
resistance, where comparisons ignore ordering).
Some information about the number of input messages is leaked, when
the combining operator is addition.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOOlilTkCAxeYt5gVAQFR1wf/UHfmFvSPyGTih0edLDoqZqKmEE3DA48q
iYQJurN/ba4TIXMo110G19NwELzGNpgwdUkZxJjrEVQZrgxpUVnT8Hc+lsMnqG58
weW/NMtgGST3nZ7JE554NGIEQ0CtavmxGUtyRgZVY4G4T1xftEOb/Dd6wv9zH8mr
cqNU1493CyVzRBafHsUotBaV28uS1jpwvMYXF1eEQSsi9j/364twtixnn1nGoZw1
VZIZwHZRl5d7EC67dDyUcC/Z8JcyoWCUXLWZwjUHP681z2vnHj7sXdxLIXE2LDFC
rN7RP1DMWAbFaGQ//BD2qCBiSN0FyHzOEHz/+FUt7kHp40aanAWPEw==
=F2bD
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: GSM A5/1 Encryption
Date: 3 Apr 2000 23:53:46 -0700
Matt Linder wrote:
> My question is how difficult is it or would it be to decrypt (in real
> time) the over the air voice traffic in GSM (and TDMA) that have been
> encrypted using the A5/1 stream cypher?
Correction: TDMA (IS-136) does not use either A5.
> I have done some research on the internet, and have found conflicting
> information. some make it sound like its not so hard, but others make
> it sound almost impossible (especially in real time) I think the latter
> is the general consensus.
> My naive understanding is that with a 64 bit key, it would take forever
> to try each key.
> What is the truth?
Well, if you think you want the truth, I don't
know why you are here, but you can trust me...
The key in current, deployed, GSM systems is
artificially limited to 54 bits, not 64. (See
www.scard.org). Even then, brute force is
difficult but not infeasible. However you've
specified "real time"... if an average call lasts
2 minutes, you don't have a big enough budget to
break it before it ends. (Of course you could
record it...)
Biryukov/Shamir/Wagner have the combined technique
that Tom mentioned, however it assumes *known
plaintext*. While I agree that it means A5/1 is
cryptographically broken, known plaintext for a
voice call is pretty hard to arrange, what with
vocoder compression and stuff happening to the
signal. It is much easier for a data call
though... send the guy some spam and wait for him
to download it, then read the rest of his email at
the same time. It is this difficulty which
accounts for the crypto people saying it is broken
and the telephone people saying it isn't.
hope that helped,
Greg.
>
>Truth is very real attacks with O(2^40) exist and probably much lower.
>There is an attack given two large hard disks you can find the key in
>seconds. But that's very unpractical for the avg joe. Doing O(2^40) of
>A5/1 will take a while, but is not impossible.
>
>> I have seen some ads from companies like G-com in new york that
>> advertise GSM intercept equipment for sale (to law enforcement only of
>> course !)
>> P.S. Some people imply that the NSA made it weak on purpose, but after
>> doing some research it sounds like it would be difficult even for
>> them. Do you think they have a machine that can do it?
>> thanks.
>
>Nope. The avg joe can decrypt A5/1 encrypted messages in a matter of a
>week or so at the most. It's just not a secure cipher.
>
>I think it's www.iyj.com or something that talks about it in more
>detail.
>
>Tom
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
** 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
******************************
