Cryptography-Digest Digest #883, Volume #11 Mon, 29 May 00 03:13:01 EDT
Contents:
Re: Another sci.crypt Cipher ([EMAIL PROTECTED])
Re: A Family of Algorithms, Base78Ct (wtshaw)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (James K)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (James K)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (James K)
Re: Is OTP unbreakable?/Station-Station (Joaquim Southby)
Re: No-Key Encryption (Michael Pellaton)
Re: No-Key Encryption (Decklin Foster)
Re: My simple cipher ("Scott Fluhrer")
Re: Crypto patentability (Anders Thulin)
Re: encryption without zeros (zapzing)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another sci.crypt Cipher
Date: Mon, 29 May 2000 04:59:31 GMT
...
>
> I believe the differential for 16 rounds will be 2^-60. A 2R or 3R
> attack could probably be mounted requiring 2^48 plain/cipher text.
>
> R p1 p0
> 0 0 c prob = 1
> 1 c 0 2^-6
> 2 c c 2^-6
> 3 0 c 1
> 4 c 0 2^-6
> 5 c c 2^-6
> 6 0 c 1
> 7 c 0 2^-6
> 8 c c 2^-6
> 9 0 c 1
> A c 0 2^-6
> B c c 2^-6
> C 0 c 1
> D c 0 2^-6
> E c c 2^-6
> F 0 c 1
> c 0 cipher text
Tom,
I have extended this attack via related keys. TC1 is vulnerable to
differential related key cryptanalysis. For best results the attack
requires chosen plain text.
The attack requires a related key query. Basically, I want to two keys
that have only a difference in the 0 word with the XOR being 0x00 00 00
0c
The attack requires some text be run under one key, and some text be
run under the related key.
The key schedule is
0,1,2,3, 1,0,3,2, 2,3,1,0, 3,2,0,1
Now since the attack can chose the plain text, the input will always be
equal to 0x00 00 00 0c thus offseting the difference in the first round.
With such a situation, the attack will have equal input to the fifth
round i.e. differential 0x00 00 00 00.
K R p1 p0
c 0 plain text
0 0 0 0 prob = 1, Since key 0 differential is 0xc
1 1 0 0 1
2 2 0 0 1
3 3 0 0 1
1 4 0 0 1
0 5 c 0 2^-6 the 0 key introduces a difference
3 6 c 0 2^-6 the key difference does not carry forward
2 7 c c 2^-6
2 8 0 c 1
3 9 c 0 2^-6
1 A c c 2^-6
0 B c c 2^-6 the difference is caused by the key difference
3 C 0 0 1
2 D 0 0 1
0 E c 0 2^-6 the zero key cancels the difference
1 F c 0 1
x c assume the differential held if p0 = c
The full differential has a 2^-42 chance. A 2R attack has a chance of
2^36, now we are getting somewhere! The attack is similar to the
differential related key attack on GOST proposed by Wagner, Scheiner,
et al.
The full attack would need one related key query and around 2^36 texts.
The counting requirements would run up the RAM to 2^32 or so.
I noticed you have modified the cipher from the original so this attack
may no longer be valid. The addition of round counters will be
irrelevant to this attack.
This is a great cipher for study. Not to hard, not to easy, just right.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A Family of Algorithms, Base78Ct
Date: Sun, 28 May 2000 23:20:19 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> While I have from personal experiences certain reservations against
> introducing complexity, which can be a considerable source of
> troubles/errors for implementations of all kinds of software, crypto
> or not, I think you are right in the opinion that computers have
> rendered the balance of crypto designers and analysts in favour of
> the former. For it is now not very difficult and indeed quite speedy
> to incorporate into an encryption scheme a tiny piece of additional
> this and that, which could considerably confound the opponent,
> who by nature has to play the passive role in the game. The diversity
> or variability in crypto design is in my humble view somewhat
> analogous to the mutations of bacteria and viruses in the microbiology.
> While in the case of e.g. flus the pharmaceutical industry is known to
> have some success in developing vaccines anticipating new mutations
> in the natural environment, it is not apparent at all, however, that the
> analyst could do anything parallel to face the variations of encryption
> algorithms. Presumably, though, this view is unlikely to be accepted
> by those who advocate the use of one single (almost) perfect
> algorithm.
>
> M. K. Shen
> ------------------------
I admit it: I am and was never much good with pencil and paper, even
though it once that was the only cipher option. I tend to use computer
helps that I write myself, starting with constructions to understand
algorithm mechanisms.
There is a debate amongst ACA'ers about comparing computer vs. hand
processed work. Those that use automated means say that the skill in
programming should be as respected as those that slave solutions out the
old fashioned way. I wish I had the natural abilities of so many gifted
hand solvers, but I don't.
There are some of us that feel that a whole area is pending where a
contest would be in solving through programming. Surely, not only older
algorithms need be attacked, but neoclassical ones as well. Otherwise,
you can get tied down to only doing just the considerable challenges that
are available to all since the 1930's. That is honorable, but life is too
short to only knit sweaters if you have competing aspirations. I find it
so, particularilly now since I can hardly use a pencil for more that a few
minutes.
It remains the lot of some of us to design and solve almost exclusively
for and with computers. The ante is raised to try to break the more
elaborate ciphers that are produced, even those with an obvious classical
flair.
The perfect algorithm is surely in the eyes of those that happen to be
seeing what they would hold most highly, rejecting anything unexpected.
Neoclassical methods, computer inspired shortcuts through complexity,
surely can assist in theory toward ideal ciphers, whatever they are.
Neoclassical methods mean being able to try new things not worth the
hassle before. Surely every attempt will not lead to a result that will
satisfy all, but much is to be learned, at least on a level of finding new
primatives.
Of course, different projects of mine have reached greater or lesser
approaches to cryptological perfection. But, I pick each wave and chose
the current one to ride for now, just for the fun of it, the intrinsic
goal in learning.
Those that want a single magic bullet may aptly find one, or it will find
them. Their expectations are to be dashed if they succeed, for there will
be no more challenge; the end is certain if the power to be novel is
terminated through political means as natural conflicts are declared
unnatural. If for some the answer to the stuggle of human existance is
stop the world and get off, whosoever should go ahead and leave so as not
to distract the rest of us from our work of improving the human condition.
--
If a privacy policy is longer that 250 words, it is already
deceptive; the longer the more deceptive.
------------------------------
From: James K <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: 29 May 2000 00:57:07 -0500
Shut up SPAMMER
On Sun, 28 May 2000 00:01:08 +0100, Joe@Joe's.bar&grill.org wrote:
>On Sat, 27 May 2000 22:15:07 GMT, [EMAIL PROTECTED] (Steve) wrote:
>
>>On Sat, 27 May 2000 17:38:32 +0100, Joe@Joe's.bar&grill.org
>>wrote:
>>
>>>And exactly how are they to defend themselves against the constant
>>>barrage of lies regarding their software? If they do not defend
>>>themselves, the lies will become truth in the minds of most.
>>
>>Every EE thread I've seen for weeks now has been started by EE
>>spam.
>
>Get real! They reply to scurrilous attacks. Unless you wish to claim
>that they themselves are "planting" these attacks.
>
>>The only "lies" I have seen have been EE claims that their
>>stuff defeats forensic software "costing thousands of dollars",
>>followed by a consistent refusal to name the software they
>>tested it against.
>>
>They have repeatedly told people to download the forensic ware and see
>for themselves. I personally have not seen one reply where their
>detractors have tried forensic methods on EE and said it failed the
>test. As usual on Usenet, it's easier to shoot off your mouth than to
>produce real proof.
>
>>Fake controversy calculated to draw attention is all I see in the
>>EE threads.
>
>Oh, then you DO accuse them of planting these attacks on themselves.
>
>> That, and a couple of people who had their system
>>registy eaten by an early, buggy version of EE,
>
>This could have been the result of many other pieces of software on
>their machines. Windows itself is the buggiest piece of crap in the
>world.
>
>> and a bunch of people pissed off at EE for spamming.
>>
>
>Defending themselves against mean spirited agendists such as you is
>NOT spam.
>
>>>Make no mistake about it -- some people are out to deliberately
>>>destroy this product. EE is not merely indulging themselves in the
>>>art of spamming. I think they are fighting for their corporate life.
>>
>>If they are fighting for their corporate lives, it is because
>>they shoot themselves in the foot every time they fire up a news
>>reader and say, "oh goody free advertising, that's what
>>newsgroups are for".
>>
>>Which reminds me to mention:
>>
>>Eraser does 99% of the job EE does, for free, without added
>>system overhead.
>
>Eraser is an overly complicated technoid's toy, worthless and
>dangerous in the hands of the naive. Naive meaning most of us who
>don't give a rat's behind how things are done as long as they are done
>and done right. Eraser's Help section is a technnoid's delight, but a
>laymen's nightmare. Not all of us give a fig about registry streams,
>let alone know that they even exist. This is one reason EE shines.
>Their Help section is a delight in clarity. Their program knows what
>has to be done and does it. I don't have to know squat. The latter
>is called good marketing. How far would the Web gotten if every thing
>was still non gui -- meaning DOS or UNIX?
>
>> Just add any files and directories you consider
>>sensitive to the task list, and choose whether to wipe them on
>>schedule or on demand. http://www.tolvanen.com/eraser/
>>
>Yeah, right. Like some of us even knew or cared that a RECENT
>directory even existed.
>
>>Remember, a dollar spent with EE, is a vote for spam in
>>newsgroups.
>>
>A dollar spent for EE is a vote for individual freedom of thought and
>the right to privacy.
>>
>>>I bought it awhile back and use it everyday. I think it's one the
>>>most indispensable pieces of software I own.
>>>
>>>Did it ever occur to you that maybe some of EE's chief detractors wear
>>>badges?lll
>>
>>If you have a real reason to worry about people who wear badges,
>>you better start worrying about your ISP logging all your
>>internet traffic, and handing over your archived e-mail
>>(typically four to six months of it), both of which are routinely
>>done by most ISPs at the request of any officer of the court.
>
>>You should also worry about packet sniffers, keyloggers, remote
>>administration tools, and BTW check your network and file share
>>settings.
>>
>There are some thing one can cure; there are other things one has to
>live with on the Web. Proxies, encryption, are some of the ways
>around many of the problems. The problem really is that the average
>Web user is only beginning to find out how vulnerable they are on the
>Web. EE is a clear solution in helping them be less so.
>>
>>Evidence Eliminator does not eliminate evidence, it just
>>overwrites files and clears some registry keys.
>
>That's hooey! Your getting really desperate now.
>
>> Any advantage
>>this might present in defending a criminal case, is more than
>>outweighed by the psychological impact on the jury of the name
>>"Evidence Eliminator". If you are counting on it to keep you out
>>of jail, be afraid. Be very afraid.
>>
>Oh, now you offer as "proof" your mind reading ability in regard to
>juries? In other words, like the O.J. pack of idiots, all juries
>don't listen to "evidence." They simply go on hunches and their gut
>feelings. Boy, are we taxpayers wasting money on prosecutors and
>evidence. With this knowledge, we can now save ourselves the expense
>of the cops having all these forensic labs at their disposal. Who
>needs evidence? After all, would a cop lie? Ha! They're the biggest
>liars on the face of the earth.
>
>- Joe -
>
>P.S. I think this summer I'll get a T shirt made that says, " I LOVE
>my EE"
>
>>:o)
>>
>>
>>Steve
>>
>>---Support privacy and freedom of speech with---
>> http://www.eff.org/ http://www.epic.org/
>> http://www.cdt.org/
>>
>>PGP keys: RSA - 0x4912D5E5 DH/DSS - 0xBFCE18A9
>>Both expire 5/15/01
>>RSA key available on request
------------------------------
From: James K <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: 29 May 2000 00:57:09 -0500
This is more bullshit SPAM, posted by the dickhead who is pushing that
piece of crap EE.
On Sat, 27 May 2000 17:38:32 +0100, Joe@Joe's.bar&grill.org wrote:
>On Sat, 27 May 2000 11:12:21 -0500, No User <[EMAIL PROTECTED]>
>wrote:
>
>>Klaus Daehne wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Besides the fact that EE is crossposting and posting off topic, I
>>> wound up downloading their product before this debate started, and
>>> (so far) have nothing bad to say.
>>
>>Yes I think this needed saying.
>>
>>EE seems a excellent product and it's important to remember that even when
>>EE Support in this group is really pissing people off, and it really is,
>>EE. It's time you stuck to what you do best, writing software.
>>
>>See how irritating repetition is?
>
>And exactly how are they to defend themselves against the constant
>barrage of lies regarding their software? If they do not defend
>themselves, the lies will become truth in the minds of most.
>
>Make no mistake about it -- some people are out to deliberately
>destroy this product. EE is not merely indulging themselves in the
>art of spamming. I think they are fighting for their corporate life.
>
>I bought it awhile back and use it everyday. I think it's one the
>most indispensable pieces of software I own.
>
>Did it ever occur to you that maybe some of EE's chief detractors wear
>badges?lll
>
>-- Joe -
------------------------------
From: James K <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: 29 May 2000 00:57:19 -0500
This is more bullshit SPAM, posted by the dickhead who is pushing that
piece of crap EE.
On Sat, 27 May 2000 11:12:21 -0500, No User <[EMAIL PROTECTED]>
wrote:
>Klaus Daehne wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Besides the fact that EE is crossposting and posting off topic, I
>> wound up downloading their product before this debate started, and
>> (so far) have nothing bad to say.
>
>Yes I think this needed saying.
>
>EE seems a excellent product and it's important to remember that even when
>EE Support in this group is really pissing people off, and it really is,
>EE. It's time you stuck to what you do best, writing software.
>
>See how irritating repetition is?
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?/Station-Station
Date: 29 May 2000 06:03:55 GMT
In article <8gqoic$[EMAIL PROTECTED]> Guy Macon,
[EMAIL PROTECTED] writes:
>No. If I use any of the standard authentication protocols,
>someone who knows my plaintext but not my key and who can
>intercept my ciphertext and replace it with his own cannot
>send a message that looks like I sent it. In the case of
>checksum followed by OTP encryption, he can. This is the
>classic man-in-the middle attack combined with the classic
>known/chosen plaintext attack. Good security systems resist
>these attacks, singly or in combination. OTP doesn't.
>
Perhaps the arguments against your statements are springing from the fact
that you denigrate OTP using attack scenarios that are somewhat unusual.
The attack you described on OTP entails finding plaintext that matches a
particular cyphertext that you have managed to intercept and also prevent
from reaching the intended receiver. That's some set of circumstances.
If you want to posit such a string of events, then I will reply that no
authentication scheme works because I could simply beat the
authentication info out of you and use it in messages to your confreres.
Now let's talk about angels dancing on heads of pins.
------------------------------
Date: Mon, 29 May 2000 08:09:41 +0200
From: Michael Pellaton <[EMAIL PROTECTED]>
Subject: Re: No-Key Encryption
It seems to me that I used the wrong name of a method of encryption.
Maybe it's an error that occurred during translation from and to
German (I have seen the word "no-key encryption" in at least two
German books).
I'd like to explain what I mean with "No-Key-Encryption" in a
small example:
Assume Alice wants to send a message to Bob.
The message is M = 10101100
Alice has a private key A = 11011001
Bob has a private key B = 00010111
Now, Alice encrypts her message with her private key
M XOR A = Ma = 01110101
and sends Ma to Bob. Bob can't decrypt the message, but he can
encrypt it again using his key
Ma XOR B = Mab = 01100010
Now Bob sends Mab back to Alice. She decrypts it with her key A
Mab XOR A = Mb = 10111011
and again sends it to Bob who is now able to decrypt the Message
with his key
M = Mb XOR B = 10101100
Maybe the methode should be called "no public key" or "no key
exchange" encryption.
It allows two people or systems to communicate safely without knowing
anything about eachother except for the fact that it uses the
same encryption system.
I know that XOR is a very weak encryption methode and I just used it
to show what I mean with "No-Key encryption" in an easy way.
Now, what's the proper English name for what I described above?
Where is it used?
Are there any well-known implementations?
Thanks for your help
Michael Pellaton
Michael Pellaton wrote:
>
> In the literature about cryptography I often read about the three
> different types of encryption - symmentric, asymmetric and Nop-Key
> encryption. I found plenty implementations of the symmetric and the
> asymmetric methode. Is there any implementation of no-key ecnryption
> available?
------------------------------
From: [EMAIL PROTECTED] (Decklin Foster)
Subject: Re: No-Key Encryption
Date: 29 May 2000 06:24:01 GMT
Michael Pellaton <[EMAIL PROTECTED]> writes:
> Now, Alice encrypts her message with her private key
> M XOR A = Ma = 01110101
>
> and sends Ma to Bob. Bob can't decrypt the message, but he can
> encrypt it again using his key
> Ma XOR B = Mab = 01100010
>
> Now Bob sends Mab back to Alice. She decrypts it with her key A
> Mab XOR A = Mb = 10111011
>
> and again sends it to Bob who is now able to decrypt the Message
> with his key
> M = Mb XOR B = 10101100
Unless I'm missing something, this doesn't make sense. An eavesdropper
would see M+A, M+B, and M+A+B, and thus would able to recover M, A,
and B.
--
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: My simple cipher
Date: Sun, 28 May 2000 23:14:32 -0700
<[EMAIL PROTECTED]> wrote in message news:8grvgp$76o$[EMAIL PROTECTED]...
> Hi, I've been lurking a while and thought I'd post this for some peer
review.
> I came up with a simple cipher with some common characteristics to
ARCFOUR,
> and I was wondering have I done anything blatantly stupid <G>. The
comparison
> is on
> < http://www.karma.tj/enc.html >
> If anyone wants to have a look. It's not exactly clear though :/
Let's state the algorithm (if I get something wrong, please correct me):
The variables are:
- A counter i
- A constant len_key, this is the length of the key used
- An array key, of size len_key. Each element in this array holds a
value 0-25 (and, unlike Arcfour, duplicates are allowed)
The key setup places the key into the array key. Presumably, the counter i
is initialized to 0.
The encryption of the plaintext array P[] of values 0-25 into the ciphertext
array C[] of values 0-25 works are follows:
i++;
Q = (P[i] + Key[i mod len_key]) mod 26
Key[i mod len_key] = (Key[i mod len_key] + Q) mod 26
Exchange( Key[i mod len_key], Key[Q mod len_key] )
C[i] = Q
Some notes:
- I will assume the attacker knows (or guesses len_key). If he doesn't, he
can iterate over the plausible values -- there are not that many of them.
- This works on values 0-25. This range is less than totally useful unless
you are encrypting sets of uppercase letters, which may have been common in
the days of manual crypto, but is rare now. BTW: Replacing 26 with 256
makes the system *much* weaker -- given a long sequence, you can uniquely
decrypt after about 256*len_key bytes with no knowledge of the key(!)
- All modifications of Key are visible to the attacker, because he knows the
values of i and Q at every point. That is, at any point in the cipher, he
knows for every x, the values of a, b and c such that:,
Key'[x] = (2**a) * Key[b] + c mod 26
(where Key' is the current contents of the Key array and Key is the original
contents). This is why replacing 26 with 256 would be so weak: if a gets
large enough, (2**a) * Key[b] == 0 mod 256, and so the attacker will know
the contents of the current Key array, even though he may have no knowledge
of the initial key, and if the plaintext is random data.
- If the attacker knows (or guesses) a plaintext character that corresponds
to a ciphertext character, he can deduce a single element of the Key array.
This is done by:
C[i] = (P[i] + Key[i mod len_key]) mod 26,
or,
Key[i mod len_key] = (C[i] - P[i]) mod 26
(where Key here is the Key array immediately before the step).
- If the attacker knows (or guesses) an element of the Key array, he knows
the values of certain plaintext characters -- the plaintext characters that
arise when that Key array element (taking the swaps into account) are under
'i'.
This immediately leads to a ciphertext-only attack: guess the value of a
plaintext character. This will give you the values of a number of other
plaintext characters. Check the values of those characters with the known
plaintext statistics. If they disagree, you guessed wrong -- try again. If
the statistics are right, guess another plaintext character, and continue
until you have revealed the entire plaintext.
> Anyway, sorry to intrude, nice group btw.
Hey, you're intruding??? You're no more intruding than anyone else here...
--
poncho
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Crypto patentability
Date: Mon, 29 May 2000 06:47:51 GMT
Mok-Kong Shen wrote:
> Are you saying that, for example, rotation by 5 bits is patentable but
> rotation by n bits, with n dynamically determined, is not patentable?
> Or do you mean that rotation CAN be one element in a specific sequence
> of operations that is a patentable?
The xor operation has been patentent (and maybe still is) as a method for
producing a cursor on a bit-mappoed display.
It's not the operation in itself that's patented, but the use to which it is
put.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Hjälmaregatan 3B, 212 19 Malmö, Sweden
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: encryption without zeros
Date: Mon, 29 May 2000 06:51:19 GMT
In article <rb-8EEF1C.22270328052000@news>,
rick2 <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, lcs Mixmaster
> Remailer <[EMAIL PROTECTED]> wrote:
>
> > Rick - You could use a regular encryption function like triple DES,
> > but if you get an output block which has a zero byte in it, run that
> > block through the encryption function again, and repeat until you
> > don't get any zeros.
> >
> > DES uses 64 bit (8 byte) data, so the chances of getting a block
with a
> > zero is 8/256 or 1/32, so you won't have to repeat the iteration
very
> > often, and almost never have to do it twice.
> >
> > To decrypt, do the same thing: decrypt the data block, and if it
comes
> > out with a zero, decrypt it again. This assumes your input doesn't
> > have any zero bytes either, so that the decryption can recognize
when
> > it is through.
>
> Excellent idea! I think I would rather give up a bit of time and
> battery to keep memory expansion to a minimum. Your idea provides
> a way to get zero memory wastage, with relatively little cpu
> penalty.
>
That really was an excellent idea!
And it occurs to me that it also gives a way to
RSA encrypt or decrypt arbitrary block sizes.
(the really small blocks wouldn't work
well of course, but ...)
Consider: RSA maps a number from 0 to M-1 to
another number in that range. But M-1 is never a
power of 2. Most messages have to be a power of
2, though, so what you would do is select the
largest n such that 2^n is less than M-1.
then to encrypt a message that is between 0 and
2^n you just run RSA encrypt on it. If the
result is >=2^n then do it again until you get
a resulting ciphertext in the range 0 to
(2^n)-1.
To RSA encrypt larger blocks, just encrypt
in blocks of n bits, moving along until
you get to the end, at which point the last
block will overlap.
This could make protocols that require RSA
en/decryption by multiple parties alot easier!
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
