Cryptography-Digest Digest #821, Volume #9 Fri, 2 Jul 99 12:13:03 EDT
Contents:
What is decorelation (in a nut ... :) ) ([EMAIL PROTECTED])
Re: Encrypted Boot Sector ([EMAIL PROTECTED])
Re: additive RNGs ([EMAIL PROTECTED])
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (DJohn37050)
Re: Contest Update ([EMAIL PROTECTED])
Re: How do you make RSA symmetrical? (Gilad Maayan)
Re: Secure link over Inet if ISP is compromized. (Patrick Juola)
Standard Hash usage (Keith A Monahan)
Re: additive RNGs ("Oliver Wiedemann")
Re: Quantum Computers (Patrick Juola)
Re: How do you make RSA symmetrical? ([EMAIL PROTECTED])
Re: How do you make RSA symmetrical? (Bob Silverman)
Re: Reference Implementation of Quadibloc S (John Savard)
Re: Can Anyone Help Me Crack A Simple Code? (Jim Felling)
Re: Reference Implementation of Quadibloc S (John Savard)
Re: additive RNGs ([EMAIL PROTECTED])
Re: Standard Hash usage ([EMAIL PROTECTED])
Re: How do you make RSA symmetrical? (Jim Felling)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: What is decorelation (in a nut ... :) )
Date: Fri, 02 Jul 1999 12:10:37 GMT
Wow lots of questions ...
Anyways. What is the basic decorelation module? I have read the
papers (from Vaudenay). Is it just
((ax + b) mod p1) mod p2
Where a and b are the ... (insert def here) and x is the input. p1 and
p2 are the two reduction parameters?
In DFC they used ((ax + b) mod 2^64 + 13) mod 2^64 is that because 2^64
+ 13 is prime and forms a permutation (of the input) ?
So a 16-bit module would be in the form
((ax + b) mod 2^16 + 1) mod 2^16
?
Thanks,
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encrypted Boot Sector
Date: Fri, 02 Jul 1999 11:59:32 GMT
In article <[EMAIL PROTECTED]>,
Zachary <[EMAIL PROTECTED]> wrote:
> I have a encrypted boot sector. And then I have the same boot sector
> but its not encrypted. Is there anyway to find out logarithm that was
> used to encrypted it. I know that it is in base 64. If that helps
> you. Are there any programs that can find the logarithm? Any
> inforamation on decryption would be helpful.
Most silly viruses do not use really strong encryption methods. They
are designed to annoy you. From what I have heard is that
most 'strong' methods (they think they are strong until you break
it...) is a repeated xor of some key value. Here is what you do....
Take the encrypted and decrypted sectors and 'xor' them together. See
what is the result. You may find a surprise. If it is random junk I
would check for other things such as LFSR or additive RNGs. If not
well just run
MSDOS---> FDISK /mbr
from a floppy disk then on your HD. That should replace the boot
sector.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: additive RNGs
Date: Fri, 02 Jul 1999 11:53:26 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> If you're storing one bit per byte, which is the easiest way to
> program such algorithms in C, this is almost the right approach.
> However, you should use memmove(), not memcpy(), because the
> latter can malfunction when the source and destination overlap.
I am doing word sized elements (for brute force searching I am using
byte size...)
> > 2. What is the cycle length for various array sizes.
>
> It depends on the feedback function. Golomb's book "Shift
> Register Sequences" (available from Aegean Park Press) is a
> good introduction to this subject.
Is there any specifics? I know that for these types there are two
parameters for length it is a(2^n) where n is the word size in bits
and 'a' is the multiplier. For example with (4, 1, 0) I got 7.5(2^n)
with (7, 1, 0) I got 63.5(2^n)... etc...
> > 3. Are all LFSR polynomials good for this type of RNG?
>
> No, for maximal period the characteristic polynomial must be
> irreducible, and unless 2^n-1 (n = # stages) is prime, not
> all irreducible polynomials yield maximal period. This is
> covered in Golomb section 3.4.
Well I don't have the book so can you spare me a bit. Max period in
these though is (2^n)-1 which is fairly easy to obtain with the LFSR
registers I have tested (note 5, 2, 0 doesn't work and I don't know
why!)
> > 4. The additive generator is linear? Is it at least statistical
> > sound?
>
> Whatever that means. Golomb discusses the "randomness" properties.
> He also has a lot about nonlinear feedback shift registers.
Well is the output at least balanced between 0 and (2^n)-1? Are there
odd/even characteristics (as in the LCG)? etc...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 02 Jul 1999 12:48:01 GMT
Yes, NIST by their very publishing of these curves is asking anyone and
everyone to take their best shot and try to break one.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Contest Update
Date: Fri, 02 Jul 1999 11:55:12 GMT
In article <7lhhbg$u22$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> The next hex character is know at web site for the
> scott19u.zip contest. And yes this contest is designed
> in a way all of the weak AES candidates usings FIPS
> chaining where the file length does not change could
> not run a similar contest because they are all weak
> compared to mine. The contest is designed to show that
> try the same thing with any of the other methods if you
> dare. They lack the critical safety features that are found
> in scott19u.zip. The main reason they lack such features
> is so that the NSA can most likely read which ever one
> is crowned the winner.
Stop posting in this group. You are such a dolt it is not funny. You
haven't read my earlier (about two weeks ago) post did you? That's
because you either a) don't care or b) don't know how to answer the
questions...
Sad... Really...
Tom
>
> 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
>
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Gilad Maayan)
Subject: Re: How do you make RSA symmetrical?
Date: Fri, 02 Jul 1999 12:17:51 GMT
On 2 Jul 1999 08:25:48 GMT, David A Molnar <[EMAIL PROTECTED]>
wrote:
>Out of curiosity, are you trying to use the public key as
>some kind of identification mechanism which can't be tampered
>with by the user ?
As a matter of fact, yes. Because of the nature of the medium, the
user won't have a chance in hell of tampering with it (and even if he
did it wouldn't do him much good), but the point is identification.
>Can you tell us about your application? It's unlikely, but
>there may be a protocol from off in the wilderness which
>is more effective than what this thread has been
>hashing out.
Naturally, I can't give any explicit details, but in general, this is
what I'm trying to do:
Take a function of the time (output: 20 bits), encrypt it using a
large e (around 70-80 bits), and a 96-bit modulus. Each user has a
unique secret key and modulus, but d, or the decryption key, is
universal.
So what the system does is ID the user (or who he claims to be), get
his modulus from a central database stored in RAM, and decrypt the 96
bits he generated using the decryption key and the relevant modulus.
The system gets back the original 20 bits, compares them to time-now,
and if equal, positively IDs the user.
Naturally, if someone attempted to identify himself as a user without
having that user's unique encryption key, even if he knew the
appropriate 20-bit plaintext, his cyphertext would decrypt to garbage
when using the correct modulus.
Another possible attack on the system would be a plaintext-cyphertext
analysis. This might yield _a_ key that would 'work' - turn the given
plaintext into the given cyphertext - but out of 2^96 keys, the
probability that that key would be the 'right' one is remote.
Furthermore, there's absolutely no way to check which key is 'right'.
You could obtain a million keys that 'work', and never know which one
was actually used.
In all of these operations, of course, the modulus and encryption key
are kept secret. Due to the nature of the medium, they cannot be
discovered in such a way that would break the system. The decryption
key is not published, but is assumed known. And that's that.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Secure link over Inet if ISP is compromized.
Date: 2 Jul 1999 09:21:26 -0400
In article <7lhmni$9ti$[EMAIL PROTECTED]>,
Gene Sokolov <[EMAIL PROTECTED]> wrote:
>
>Patrick Juola <[EMAIL PROTECTED]> wrote in message
>news:7lgduf$p3p$[EMAIL PROTECTED]...
>> In article <7lgcjq$g5r$[EMAIL PROTECTED]>, Else <[EMAIL PROTECTED]> wrote:
>> >
>> >Patrick Juola wrote in message <7lfspi$mij$[EMAIL PROTECTED]>...
>> >>In article <7lfi2r$38f$[EMAIL PROTECTED]>,
>> >>Gene Sokolov <[EMAIL PROTECTED]> wrote:
>> >>> What do you think is the fraction of the Net users who exchange
>keys
>> >>>"out of band", i.e. not through their ISPs?
>> >>
>> >>My PGP public key is available through a half-dozen different sources,
>> >>including one in print (Proc. NeMLaP-2); if the FBI decides to tamper
>> >
>> >What do you think is the fraction of people who do likewise?
>>
>> Anyone who signs up with the MIT key database, for one.
>>
>> Anyone who *has* ever exchanged a key with someone prior to
>> the discussion at hand.
>
>What do you think is the *fraction* of people who do likewise?
>Let's make the question simpler simpler:
>100 people use SSL. What do you think is the number of people out of 100 who
>exchange keys before starting data exchange?
99, probably. I can't imagine more than 1 in 100 people only using
SSL once in their life and never again.
Once you've exchanged the key with the first person, that person has
a copy of your key and can constitute a second channel that The Man
would block separately.
>> Anyone who makes backups of their system(s).
>
>How is that relevant?
'Cause your key is available on the backup tape.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Standard Hash usage
Date: 2 Jul 1999 13:54:31 GMT
I've noticed on a few encryption packages that after the "entering password"
stage, the programs run your password through some sort of hashing
algorithm like SHA-1 and MD5. Is this common practice?
Now, from what I can tell, it appears the main reason for doing this is to
take an arbitrary length password, and turn it into some fixed length key
for usage in the encryption algorithm. I can understand the reasons for
having a fixed length key, but what added security does running your pw
through a hash get you? My guess is that it turns your password from a
limited typed (ie printable, perhaps) characters set of maybe 150 chars and
increases it to the whole range of 255 per byte.
So I suppose it could be said that a hash algorithm increases the entropy
of the password?
I noticed that SHA-1 outputs a hash result of 160 bits. What if
the result you need is larger than that, say 256 bits? (ie, for
Blowfish perhaps) And if the answer is, "Just run SHA-1, twice", then
how much data do you pipe in from the original key the first run, and the
second run? Do you just concatenate the 2nd results to the first?
I'm in the process of collecting some different public domain sources
together into a brute-force cracker for Blowfish. The cracker isn't designed
to attack a large key, I need it to recover a few characters that I don't
remember on my password. Given Blowfish's relatively fast speed, I should
be able to test a decent amount of passwords per second and combine that with
some dictionary attacks and so forth, it could be a useful utility.
Thanks,
Keith
------------------------------
From: "Oliver Wiedemann" <[EMAIL PROTECTED]>
Subject: Re: additive RNGs
Date: 2 Jul 1999 13:54:12 GMT
<[EMAIL PROTECTED]> wrote:
> 1. What is the quickest way to do the shift? I.e S[0] = S[1]. S[1] =
> S[2]. I am using a memcpy (because I have a 32 element array). It is
> rather quick...
I guess the fastest way to do this is not to copy the array at all. Just
treat the array as a circular list with do indices into the array, which get
both incremented each time you call the RNG. Then just let them wrap around
and the maximum array position.
<snip>
> 5. Are there any good references (papers or sources) for them? I
> would like to compare mine to theirs.
There's a postscript document called 'keynote.ps' included in the diehard
statitical test package from George Marsaglia (see
http://stat.fsu.edu/~geo/diehard.html). This has a brief discussion of
Fibonacci lagged generators, good choices for the different parameters and
explains how to determine the period length.
Hope that helps ... Oliver
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Quantum Computers
Date: 2 Jul 1999 09:17:36 -0400
In article <7lgqef$qsg$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>
>> So why don't you do some reading, instead of scare-mongering?
>
>Because scare-mongering is more fun?
>
>No seriously, I looked at all your posts. When I said that I did not
>know of anyone's credentials to comment on my assertion, I was talking
>about those who posted back to me. However, I thought you made a good
>point. Rather than ask all of you, I should just look using the search
>engine - dah! (It's times like these that I ask myself why I bother
>getting up in the morning.)
>
>But I am curious. You are so certain that I am wrong (and dumb), yet
>you are so patient. Why? I mean, I would not bother writing back if I
>were you.
I'm a college professor (for my sins). Part of my penance involves
educating the incorrect. The rest of it involves grading papers and
tests.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How do you make RSA symmetrical?
Date: Fri, 02 Jul 1999 14:14:06 GMT
> You're right, but unfortunately I have to use a PKC. The app simply
> won't work with a secret key system. But still, since I'm planning to
> use a 96-bit modulus, my processor should be able to cut it.
> And please, people, no need to lecture me about how unsafe a small
> modulus is, etc. etc. For my very specific application, it works just
> fine.
>
Seems like you want to stop your 'sister' (excuse the saying) from
getting at some sort of transmission. In which case why not use
simpler algorithms? If you are going to use small moduluses which are
unsafe (because they can be factored easily) then what's the point?
It's an all or nothing type situation. If you just want to hinder
cryptanalysis why not just seed a RNG (I am playing with additive RNGs
now so they come to mind) and perform simple XOR ops. The cipher can
be broken rather easily but it will hamper novices (well a little)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: How do you make RSA symmetrical?
Date: Fri, 02 Jul 1999 13:42:09 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Gilad Maayan) wrote:
> On Thu, 01 Jul 1999 04:21:30 -1000, Ed Yang <[EMAIL PROTECTED]>
> wrote:
>
> >Yes. The 20 bit input would be padded with 108 leading zeros
> >whether you like it or not. You would decrypt it and get 108
> >leading zeros and 20 bits of the correct plaintext.
>
> Okay, I get it. The question is, how does this affect processing time?
It doesn't.
> The main reason I'm asking "which hammer to crush my testicles with",
> as someone put it, is that my specific application is hampered by
> severe hardware restrictions. I'm using a processor that can barely
> compute M^e, where M is 20 bits.
Huh? With RSA, you don't compute M^e. You compute M^e mod N.
> Naturally, even the slightest
> increase in plaintext size enormously increases the number of
> mathematical operations required.
Your repeated posts show that you do not understand the algorithm.
Run, don't walk, and get yourself an intrductory textbook on the
subject. Koblitz's book is nice. So is the Handbook of Applied
Cryptography. Or Schneier's book.
>Now, if you encrypted your message,
> padded with all zeroes, would my pathetically slow microprocessor be
> doing 20 bits^n, or 768bits^n?
Is N is (say) 1024 bits, and you are computing M^e mod N, then it
will not matter in practice whether M is 20 bits or 1023 bits.
Yes, if M is small then the first few multiplications you do will be
with numbers smaller than 1024 bits. But once you have done the first
6 squarings (out of 1024 needed), your numbers will have grown to the
full 1024 bits in length. The time difference for 20-bit M vs 1023-bit
M is small.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Reference Implementation of Quadibloc S
Date: Fri, 02 Jul 1999 14:51:15 GMT
[EMAIL PROTECTED] wrote, in part:
>Were you on the hill today? Heard there was a good show planned for
>tonight.
No, I live in Edmonton, which is quite far from Ottawa.
>Anyways do you have a offline copy of your quadiloc to read? The
>online webpage is hard to follow.
There is an off-line copy of the web page, and there is a pointer to
it on the entry page to the cryptography pages, just off the main
page, but it's not up to date, and it wouldn't be any easier to
understand, since it is the same stuff.
Anyhow, I've uploaded only now the description of the Quadibloc S
cipher I just implemented.
And I find I've already used the name Quadibloc S for something else!
Some tidying up is in order...
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: Fri, 02 Jul 1999 10:33:23 -0500
Is the output a code that includes the date?
Notation BB(X) = result of entering code X into the Black Box
is it BB(X)=(Light, Date), or is it perhaps BB(X, Internal clock)
=light?
I am inclined to believe that it is a hash or the like similar to
perhaps UNIX'spassword checking algorithm.
(Another thought -- if the codes are good for X days, how do you know
that it just doesn't start a counter/clock on day 1 and when that
counter rolls over, or some thing of that sort disable the chip until
reset.)
mercury wrote:
> Douglas A. Gwyn wrote:
>
> > mercury wrote:
> > > I am trying to discover an encryption algorithm
> > > by observing how it behaves.
> >
> > It's not truly encryption; it is a hash into a single bit.
> > Too much information is lost.
> >
>
> "Hash" may be a more appropriate term for what is
> going on here. The input is ten digits. Since more
> than one input reveals the same output, it is reasonable
> to assume it is somehow getting reduced to an output
> smaller than ten digits.
> However, the output is a code which represents a
> date, as well as other information, so the output must
> be larger than one bit.
>
> This would mean the input codes all contain the
> same information which is not lost in the "hash",
> then there is some added insignificant information
> which is lost.
>
> So we have 6 identical numbers with some extra
> garbage to obscure their meaning.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Reference Implementation of Quadibloc S
Date: Fri, 02 Jul 1999 15:09:48 GMT
[EMAIL PROTECTED] () wrote, in part:
>Quadibloc S is a block cipher with a 64-bit block, very similar to the
>original QUADIBLOC.
I had previously used the name QUADIBLOC S to describe a form of the
original QUADIBLOC with a specified pattern of key augmentation. In
that one, the S stood for Secure; the name of this variant has been
changed to QUADIBLOC SE to avoid confusion.
In the new Quadibloc S, the S stands for Small.
The key-dependent S-box, when the key is zero (and considerably longer
than the four bytes used in the examples) or nearly all-zero will show
some weaknesses.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: additive RNGs
Date: Fri, 02 Jul 1999 15:06:42 GMT
<snip>
The site is messed up. It had the link 'Papers related to DIEHARD' but
it didn't go anywhere... Is there a mirror site?
Thanks,
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Standard Hash usage
Date: Fri, 02 Jul 1999 15:03:45 GMT
In article <7ligan$nfs$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Keith A Monahan) wrote:
> I've noticed on a few encryption packages that after the "entering
password"
> stage, the programs run your password through some sort of hashing
> algorithm like SHA-1 and MD5. Is this common practice?
Yes.
> Now, from what I can tell, it appears the main reason for doing this
is to
> take an arbitrary length password, and turn it into some fixed length
key
> for usage in the encryption algorithm. I can understand the reasons
for
> having a fixed length key, but what added security does running your
pw
> through a hash get you? My guess is that it turns your password from
a
> limited typed (ie printable, perhaps) characters set of maybe 150
chars and
> increases it to the whole range of 255 per byte.
>
Well the range of the key is limited to the range of the input.
However hashes are good to turn a somewhat limited key (i.e ASCII
chars) into a output which is not strictly limited. This will mean
that the keys in the cipher are not limited to a certain range. It all
depends on the length of the passwd though.
> So I suppose it could be said that a hash algorithm increases the
entropy
> of the password?
No it doesn't. It just 'randomizes' it so that it's harder to predict
the range of the actual output of the hash. If you use 4 chars
(assuming 95 printables...) your password is among one of 95^4 or 2^26
others... It's a small range, however attacking the hash will require
on average O(2^159). So guessing the key actually used in the cipher
is difficult, so guessing the input (passwd) becomes the focus point.
> I noticed that SHA-1 outputs a hash result of 160 bits. What if
> the result you need is larger than that, say 256 bits? (ie, for
> Blowfish perhaps) And if the answer is, "Just run SHA-1, twice", then
> how much data do you pipe in from the original key the first run, and
the
> second run? Do you just concatenate the 2nd results to the first?
Normally It would be this
H1 = H(P)
H2 = H(P||H1)
Where P is the input and H1/H2 is the output (would be 320 bits with
SHA).
> I'm in the process of collecting some different public domain sources
> together into a brute-force cracker for Blowfish. The cracker isn't
designed
> to attack a large key, I need it to recover a few characters that I
don't
> remember on my password. Given Blowfish's relatively fast speed, I
should
> be able to test a decent amount of passwords per second and combine
that with
> some dictionary attacks and so forth, it could be a useful utility.
Well all you have todo is make a program to check keys, it is
independant of the hash and block cipher (unless the output of the hash
is less then the input in size...)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How do you make RSA symmetrical?
Date: Fri, 02 Jul 1999 11:00:13 -0500
That is basically impossible.
You could find all the M s.t.. E(M)<=set length, and then map those in
some way so as to associate them with a I s.t. 1= first such M, etc. --
but all such mappings are just permutations that just happen to have RSA
in the middle i.e. if I send a message X them the process is find I(X)
decoding is looking at a table of I(X)'s and finding which I corresponds.
Cyphertext length in RSA is always going to be approximately the length
of N-- it will be very rare for it to be shorter by an appreciable number
of bits. ( Another way of thinking about it is say I use an X bit block
cypher on my data my output will pretty much always be X bits long-- if I
make a policy of discarding leading 0's there will be occasional shorter
cyphertexts, but the will also be rare). Thinking of it this way RSA has
a block size of log2(N) bits.
Gilad Maayan wrote:
> None of you seem to realise that I was actually asking in my original
> post, was how to make plaintext length equal cyphertext length. Seems
> logical to call that 'symmetry'. I wasn't talking about symmetrical,
> or private, key systems. But feel free to carry on.
>
> Gilad Maayan
------------------------------
** 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
******************************
