Cryptography-Digest Digest #544, Volume #11 Fri, 14 Apr 00 00:13:01 EDT
Contents:
Re: Regulation of Investigatory Powers Bill (Paul Rubin)
Re: The use of Three DES (Tom St Denis)
from table to function (Tom St Denis)
Re: Encode Book? (Jim Gillogly)
Re: SSL/HTTP questions (newbie warning) (Rot 13)
Re: Q: Entropy (Bryan Olson)
Advice in my situation (Newbie) ("Fletch")
Re: Cryptanalysis Challenge - Will anyone accept? ("Jeff Hamilton")
Re: TDMA CAVE encryption (David Hopwood)
Re: Cipher Contest Update ([EMAIL PROTECTED])
Re: AND on encrypted data ("1198")
Re: AND on encrypted data ("gcouger")
BlowWire ("Spleen Splitter")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Date: 13 Apr 2000 22:35:00 GMT
In article <[EMAIL PROTECTED]>, Jill <[EMAIL PROTECTED]> wrote:
>There is no law against keeping files of random data and the protest, of
>itself, provides the reason for having this data on your computer. It
>would require the assistance of someone well versed in cryptography to
>write a program to generate the random data so that it is
>indistinguishable from an encrypted file. Key generator programs may
>work, but this is by no means certain and I am not qualified to say one
>way or the other. Perhaps someone who is qualified could suggest an
>easy means of doing this. The best way of providing these files would
>be to set up a web site which will email a ready-made block of data to
>those requesting it. There must be someone out there with the knowledge
>and the inclination to set up such a site.
This is an an amusing idea for us cryptographers. Somehow I think the
UK law enforcement troglodytes will be less than amuse :-(. Anyway, a
fun way to do it would be with the random number generation hardware
built into the Pentium III chip set. That way there would be no
cryptography programming involved.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The use of Three DES
Date: Thu, 13 Apr 2000 22:56:01 GMT
lordcow77 wrote:
>
> In article <[EMAIL PROTECTED]>, Tom St Denis
> <[EMAIL PROTECTED]> wrote:
> >The thing is attacks like Differential and Linear didn't exist
> until 10
> >years ago or so. So most attacks were 'hey I just noticed
> that...'
>
> Differential or linear analysis is not a black box that one
> feeds an algorithm to, upon which an answer will pop out giving
> the precise number of known/chosen texts are needed to break a
> given algorithm. Applying these cryptanalytical tools to a
> cipher requires a good deal of time and expertise; one cannot
> just make a cursory examinination of an algorithm and pronounce
> it secure. Moreover, one must consider variations on a basic
> idea used to attack a cipher: what notion of difference is being
> used? how can one exploit the broader structure of the cipher?
> what about interactions with the key schedule?
>
> >Just like speed'ups on the Fermat factoring method are
> noteworthy but
>
> What exactly is this "Fermat factoring method?"
Factoring via Difference of squares. It's in Knuth and I believe HAC.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: from table to function
Date: Fri, 14 Apr 2000 00:18:01 GMT
How exactly did they expand the Serpent Sboxes into a series of
algebraic instructions? Can you do this to any random permutation?
Tom
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Encode Book?
Date: Fri, 14 Apr 2000 00:33:51 +0000
Eric Verheul wrote:
> Hey, I invented Pascal when I was 10, only to find out that somebody
> beat me to it. Damn!
Ah, the tragedies of youth. I discovered the Gilloglean Theorem when I
was in junior high -- but a friend's father looked at my work and told
me it was simply the Fundamental Theorem of Arithmetic. Bummer.
My older son at age 8 ripped out the cave in the old Adventure game
("You're in a maze of twisty little passages, all different.") and
replaced it with his own. By age 12 he was earning royalties on game
software for the Heathkit H-89.
Face it -- there's somebody somewhere who's smarter than you -- except
for one of you, of course... and I'll bet he or she doesn't post to
sci.crypt.
--
Jim Gillogly
24 Astron S.R. 2000, 00:29
12.19.7.2.4, 9 Kan 7 Pop, Eighth Lord of Night
------------------------------
Subject: Re: SSL/HTTP questions (newbie warning)
From: [EMAIL PROTECTED] (Rot 13)
Date: 13 Apr 2000 17:00:52 -0700
In article <8d2vfk$qtd$[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Ken Tomei <[EMAIL PROTECTED]> wrote:
>>First, my understanding is that initial session establishment requires a
>>full handshake, including certificate exchange. Each TCP connection
>>under that session ID is initiated using a simplified handshake, using
>>the previously calculated master secret, but different client and server
>>randoms to generate different symmetric keys. Are these client and
>>server hello messages transmitted in the clear or are they encrypted?
>
>The hello messages are in the clear.
>
>>After a session is closed, can it be resumed later?
>
>This is spelled out in the spec. I'm pretty sure the answer is no
>but I'd have to check.
It can be resumed, generating a new session key from the master secret.
>
>>Also, is it possible to have multiple TCP connections open
>>simultaneously within the same session or will they always occur
>>sequentially?
>
>SSL operates at a higher level than TCP. However, in most implementations,
>you won't have several TCP connections being multiplexed into a single
>SSL connection.
SSL just requires a reliable ordered transport underneath. You could
multiplex the TCP connections underneath but I've never seen that done.
I dont' think that it would help performance much (unless there's some
sort of QOS bandwidth limit per TCP connection going on).
>>Servers typically have a session timeout counter - what exactly does
>>this entail? Is this a strict timer from the session establishment, or
>>is the counter reset with each new TCP connection? In other words, does
>>the timer only start when a session becomes inactive?
>
>It's just something that the server does at its convenience to know when
>to expire entries in its ssl session cache.
The spec also limits the number of bytes that can be sent
before renegotiating the session key (or maybe it's regenerating it
from the MasterSecret). But that number is pretty large and you're
unlikely to reach it.
>>encounter over the web? For example, I click on BofA.com and establish
>>a secure session. Are multiple TCP connections opened for each imbedded
>>object on that particular page? After I've retreived all objects on
>>that page, is the session closed or still active? When I click on a new
>>link within the secure site, do a resume the same session? open a new
>>one?
>
>I think you'd open new SSL sessions but can use cached keys. It's
>been a while since I've looked at this.
>
>>How do persistant connections affect all of this?
>
>If you mean HTTP 1.1 keepalive connections, that's independent.
SHTTP is HTTP over SSL. So you can have many HTTP connections, or
persistant HTTP connections, over one SSL connection.
>>I'm having trouble locating a good reference to understand a general
>>SSL model. Any help would be greatly appreciated.
>
>Try RFC 2246, the TLS specification. http://www.faqs.org/rfcs/rfc2246.html.
Yep. TLS and SSL are very similar, so that should explain it pretty well.
--
Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5
<IMG LOWSRC="javascript:alert('Delete C: and install Linux?')">
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Fri, 14 Apr 2000 02:23:16 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> > I've been trying to explain _how_ the issue is treated:
> > language-independant complexity is defined to within an
> > additive constant. If you know the issue is treated, why do
> > you keep ignoring the treatment? If your "shortest program"
> > comparison is language independent, what happened to the
> > +O(1) term?
>
> My argument here is certainly 'inexact', but I want to say that
> it seems to me to be likely that the O(1) term does not disturb
> a 'relative' comparison of two strings, somewhat analogous to
> measuring temperature with Fahrenheit or Centigrade.
The O(1) term absolutely does disturb a relative comparison
between constants. For _any_ two real numbers x and y,
x = y + O(1).
If x<y it's true. If x>y it's true. If x=y it's true.
You can find an excellent explanation of what the O(1) term
means in /Introduction to Algorithms/, by Cormen, Leiserson,
and Rivest, McGraw Hill and MIT Press 1990.
> > In a discussion last year, I wrote an explanation of the
> > theorem that justifies the language-independent metric, and
> > why it fails to describe finite strings. It's in a sci.crypt
> > post of 11/13/1999 in the thread 'Re: Proposal: Inexpensive
> > Method of "True Random Data" Generation". One warning: in
> > that post I assumed a "string" is by definition finite,
> > which is not the convention in Kolmogorov complexity.
>
> I am very interested to know one thing: You seem to claim that
> Kolmolgorov complexitiy is defined on infinite strings 'only'.
No, I specificly included infinite sets of finite strings.
Three days ago in a post to which you responded I wrote:
: The interesting results of Kolmogorov
: theory describe the complexity of infinite sequences or
: infinite sets of finite strings.
The post cited in the quote above says more than once that
Kolmogorov complexity is meaningful on infinite sets of
[finite] strings.
> In
> the few texts that I happened to have glanced at I found that
> in the definition of the measure the string is said to be
> 'arbitrary' and there is no mention at all of 'infinite'. Now,
> according to common (non-explicit) conventions, 'arbitrary' means
> 'arbitrary finite' if used without explicitly adjoining 'infinite'.
Hard to tell based on a one-word quote, but correct me if
I'm wrong: the meaning of 'arbitrary' in those definitions
is in the sense of arbitrarily large. If my interpretation
is correct on that, then consider the following three
questions:
Were the million-bit strings in the example arbitrarily
large? (The example from 2000-04-10 in which I claimed
Kolmogorov complexity did not say which is more
complex.)
If you have a finite set of (finite) strings, does it
contain arbitrarily large strings?
If you have an infinite set of (finite) strings, does it
contain arbitrarily large strings?
> Should I thus conclude that all these texts about Kolmogorov
> complexity are wrong?
After you "happened to have glanced at" them?
Here's an example to show the connection between "arbitrarily
large" and the +O(1) term.
Suppose I describe a function named "f" saying:
For all positive integers n,
f(n) = n/2 + O(1)
That's equivalent to saying
There exists some constant c, such that for all
positive integers n,
|f(n) - n/2| <= c.
That's a potentially interesting description of f, since
it is not true for many function. But it's only interesting
because n can grow arbitrarily large and functions of n
can dominate any constant.
If we restrict the domain of n to a finite set, then the set
of possible values for |f(n) - n/2| is finite and must have
a largest member.
Thus the following is completely vacuous:
There exists some constant c such that
for integers n with 0 < n < 10000000000000
|f(n) - n/2| <= c.
That's true for _all_ real-valued functions, so it's
worthless as a description of f.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Fletch" <[EMAIL PROTECTED]>
Subject: Advice in my situation (Newbie)
Date: Thu, 13 Apr 2000 21:31:20 -0500
OK, I am a newbie to cryptography. I have an interesting situation, and I
wondered if anyone could point me in the right direction.
I am a games programmer and am implementing a "World rankings" system for
our racer game, "4x4 Evolution." Basically, this is a list of the fastest
lap times of everyone on the internet. My security concern is that people
will be able to spoof high scores and submit times that they did not
actually get. This will ruin the whole thing.
My current plan for score submission is this:
I generates a high score submission record in plain text
I compress this record
I encrypt this record (using the most appropriate algorithm, which I
don't know what is)
I ASCII-armor the record for safe transport to our web server.
Then the data is posted to our web server. It can arrive in a number of
ways. Either the game will submit the data directly, which is what will
happen most of the time. Or, they can save the record to the hard disk (PC)
or memory card (console) and then submit the score at a later time. We are
also considering displaying the ASCII data on the screen and allowing the
player to write it down and enter this into a web page form directly, if
they don't have an internet connection but their friend does, etc.
My basic problem is that no matter what I do, I cannot guarantee security.
I know this. I have given the potential hackers a tool which they can use
to encrypt score submissions: our game. So anybody who could disassemble
the .exe could discover my encryption algorithm and any keys I am using. I
can't see any way to prevent against that. I can make it incredibly
difficult, but I cannot prevent it completely.
I see two possible attacks on my security. An offline attack (basic
cryptanalysis), and a run-time attack (disassembly, or debugging my code).
So I have two questions:
1. Does anybody have any advice to make sure that a non-disassembly attack
(basic cryptanalysis) is not possible? I do have the advantage that my
algorithm is secret. (But any keys I use have to be distributed with the
game, potentially accessible by a hacker!)
2. Are there pitfalls I should avoid to make sure a disassembly/debug attack
isn't too easy? Does anybody have any experience with how to make this as
difficult as possible?
Any advice would be greatly appreciated.
Thanks,
- Fletch
[EMAIL PROTECTED]
------------------------------
From: "Jeff Hamilton" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis Challenge - Will anyone accept?
Date: Thu, 13 Apr 2000 20:10:22 -0700
Ok, I decided to try people out on this algorithm....
"Frank Gifford" <[EMAIL PROTECTED]> wrote in message
news:8csumm$[EMAIL PROTECTED]...
> In article <8cm90d$lb7$[EMAIL PROTECTED]>,
> Paul Rubin <[EMAIL PROTECTED]> wrote:
> >In article <JVwH4.622$[EMAIL PROTECTED]>,
> >Jeff Hamilton <[EMAIL PROTECTED]> wrote:
> >>I was thinking of placing a stream cipher out here that I developed
about 3
> >>years ago. ...
> >
> >Sure, go ahead and post it. Make sure to describe the exact conditions
> >of the challenge, i.e. what does somebody have to do to collect the $100,
etc.
> >
> >>Would anyone be up to the offer? ...
> >
> >I'd say just go ahead and post the challenge: specification/description
> >of the cipher, and the sample message.
>
> It would be good to keep in mind that a cipher may be "broken" in
different
> ways. For example, the contents of a ciphertext message might be
determined
> based on a poorly implemented cipher, even though the particular starting
> key cannot be determined.
>
> So if you offer this contest, it should be a few plaintext/ciphertext/key
sets
> and then a challenge ciphertext. The goal is to recover the plaintext (or
> a significant portion of it) of that ciphertext.
>
> -Giff
>
> --
> Too busy for a .sig
>
------------------------------
Date: Fri, 14 Apr 2000 03:13:21 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TDMA CAVE encryption
=====BEGIN PGP SIGNED MESSAGE=====
Matt Linder wrote:
>
> With all this talk about GSM and A5/1 and its weaknesses, it makes
> me wonder about GSMs cousin TDMA used here in the US. I think it uses
> an algorithm called CAVE (I don't even remember what it stands for)
>
> Does anyone know anything about how good the CAVE algorithm is?
[WSK97b] says:
# The TIA standard [TIA95] describes four cryptographic primitives for
# use in North American digital cellular systems:
#
# - CAVE, a mixing function, is intended for challenge-response
# authentication protocols and for key generation.
(This is roughly analogous to A3/A8 or COMP128 in GSM.)
# - A repeated XOR mask is applied to voice data for voice privacy
# (footnote 1).
(This is analogous to, but much weaker than, A5/*.)
# - ORYX, a LFSR-basd stream cipher intended for wireless data services.
# - CMEA (Control Message Encrytion Algorithm), a simple block cipher,
# is used to encrypt the control channel [Ree91].
(The control channel includes things like dialled numbers.)
# The voice privacy algorithms has long been known to be insecure
# [Bar92] [CFP93]. Recent work by the authors has shown that ORYX is
# insecure as well [WSK97]. This paper focuses on the security of CMEA.
#
# footnote 1:
# The situation is more complicated: time-division multiple access
# (TDMA) systems use a straight XOR mask, while code-division multiple
# access (CDMA) systems instead use keyed spread spectrum techniques
# for security.
[Ree91] J. A. Reeds III,
"Cryptosystem for Cellular Telephony,"
U.S. Patent 5,159,634, September 1991.
http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&;
p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=%275159634%27.WKU.&
OS=PN/5159634&RS=PN/5159634
[Bar92] J. P. Barlow,
"Decrypting the Puzzle Palace,"
Communications of the ACM,
July 1992.
[CFP93] R. Mechaley, Speaker,
Digital telephony and cryptography policy session.
The Third Conference on Computers, Freedom and Privacy,
Bulrigame, CA, 1993 (Bruce Koball, General Chair).
[TIA95] TIA TR45.0.A,
"Common Cryptographic Algorithms,"
June 1995, Rev B.
[WSK97] D. Wagner, B. Schneier, J. Kelsey,
"Cryptanalysis of ORYX,"
unpublished?, 4 May 1997.
[WSK97b] D. Wagner, B. Schneier, J. Kelsey,
"Cryptanalysis of the Cellular Message Encryption Algorithm,"
Advances in Cryptology - Crypto '97.
- --
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
iQEVAwUBOPZ+rjkCAxeYt5gVAQGmeggAgC3HISbdxDHYy2HDJ3sa/8hcckvht9qh
COyyYNs5QrjpuSHKf4ZA2sd5YFAL5FGtB622PcteXWf4iDfrRlOdgbTOkBRV17Nv
gpeaxuYW57xKYQoDi1Hk4ENxBA4BzGYsZrzTo5rJBnXGrQ6+/5aF1QbxBN28312u
Blq1QauhWDop27/vRf5Vf+sJlAjHqqwSr6uAUdg6Zz17RR4jp0UjP/bk/hNsZnu/
/IvgdY/hsIyIzFFZL8Mt7nsnNhg32qrm1xx7iemn0jvcsKf+zdJDfD+sYpA0ycJv
IyBRHujaOxsPFNm2yNfBQcDSVyVv4JddtJM8e73RSXKMzCqydAnXIA==
=ndcJ
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cipher Contest Update
Date: Fri, 14 Apr 2000 03:07:42 GMT
In article <GD9J4.4446$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> The contest started about two weeks ago, and so far I have only
received ONE
> submission. Boris Kazak submitted a cipher named LETSIEF (Feistel
> backwards). Matthew Fisher was able to perform differential analysis
on it,
> and Mr. Kazak resubmitted his cipher. LETSIEF2 is still in the
running and
> I have no heard of any attacks on it yet.
>
> It seems very strange that so many people where complaining about how
> restrictive the requirements were when I first started talking about
the
> contest, and now that the contest has started practically no one is
> participating. I did recognize the complaints about the requirements
and
> virtually removed all the requirements. There still are two
requirements
> which are the entry must be a block cipher, and resource usage should
be
> reasonable or justified. This leads me to several possible
conclusions. 1.
> - Adam
Mr Durana,
I have a cipher, Vortex, that I will be submitting. All I have to do
is compile on an Intel box and get test vectors. I developed on
Solaris.
Vortex is a Feistel cipher (suprise) that uses a (hopefully)
differential strong F function. Only the Rijndael sbox is used. The
PHT from twofish and the a^b+c^d transform from Blowfish are used for
linear mixing.
The key schedule is mostly taken from Serpent with significant
modification in the s-box step.
I expect the cipher to be quite strong but not as fast as the AES
ciphers, we'll see.
As to cryptanalyis, don't expect too much. It is hard and tmime
consuming. Only real crypto freaks like me spend there night anlayzing
little know ciphers :-)
I saw that Mr St Denis posted a cipher the other day, he should submit
it. Also, Mr Savard has several Quadiblock ciphers on his website that
would make excellent entries.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "1198" <[EMAIL PROTECTED]>
Subject: Re: AND on encrypted data
Date: Fri, 14 Apr 2000 11:19:10 +0800
Claudio Di Flumeri wrote in message <[EMAIL PROTECTED]>...
>Does anyone know if there are encryption schemes that allow logical
>operations (AND, OR, NOT) on encrypted data?
>
Some opinion here... If you take a close look at XOR operation, with a fix
key, no two bytes of different values will produce the same result(perfect
one to one mapping). This is not true with AND or OR. (NOT is a special case
of XOR, XOR with $FF ). So you see more XOR used in encryption than others
in simple cases. Sure you can use AND or OR (even rotate, but it need less
care as XOR) in your scheme but you need more care so you can be sure that
in no case you encrypted data cannot be recovered.
------------------------------
Reply-To: "gcouger" <[EMAIL PROTECTED]>
From: "gcouger" <[EMAIL PROTECTED]>
Subject: Re: AND on encrypted data
Date: Thu, 13 Apr 2000 22:32:29 -0500
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Claudio Di Flumeri wrote:
> >
> > Does anyone know if there are encryption schemes that allow logical
> > operations (AND, OR, NOT) on encrypted data?
> >
> > I'm looking for a sort of privacy homomorphisms but with logic and not
> > arithmetic operations.
>
> Logical operations are almost everywhere in the world of encryptions.
> One could even say that, in comparison, arithmetic operations are
> used not as much. You can read any good textbook on cryptography
> to inform yourself of the matter.
>
> M. K. Shen
for(i=0; i<end-of-text; i++)
*crypt-text++=*plain-text++ ^ *key++;
This implements the one time pad and the key must be longer than
the plain text. the '^' represents an XOR or exclusive OR operation.
This method was done by a fellow in Bell Labs in the 1920's using
teletypes and paper tape.
XOR is a very fast operator that usualy translates directly to an
assmembly instruction. It is often faster to zero a variable by
v = v ^ v; than v = 0;
To decode the same function decodes the data.
for(i=0; i<end-of-text; i++)
*plain-text++=*cryp-text++ ^ *key++;
--
Gordon W5RED
G. C. Couger [EMAIL PROTECTED] Stillwater, OK
www.couger.com/gcouger
"You miss 100 percent of the shots you never take." - Wayne Gretzky
------------------------------
Reply-To: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
From: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
Subject: BlowWire
Date: Fri, 14 Apr 2000 03:59:59 GMT
Greetings:
I need something to crank on, so I decided to toy with something I fancifully call
BlowWire, which is simply a 500MHz or so fully pipelined implementation of Blowfish
in some modern technology, say 0.18um CMOS. Connecting two of these devices on a
cable seems to have enough meat on it to provoke a discussion.
After eating a key in 64 bit hunks of up to 1024 bits, this thing would have a latency
of ~18 clocks, and then treats the incoming 64-bit parallel stream as a block,
packet,...
to be encrypted/decrypted.
Software implementations are one thing, but they're slow, and I really don't want to
use a "yet-another-embedded-cpu" on this particular project (top performance required,
thus the pipeline design, which is more of my interest than say just a wire protocol).
The C code for Blowfish that I've seen, however, has guided my views on implementing
the
hardware.
I think I can do this in 60Kgates, with my biggest problem being all the simultaneous
accesses to pi during each clock (what a ROM, what wires!). I'm looking at things like
how many register files of how many ports, and what sort of ROM in how many copies.
Each round would presumably be done in a clock, thus leading to the 18 or so clock
latency to get through the pipe.
Given that I'm only doing Blowfish for fun, I'm fairly certain that further
enlightenment
could be forthcoming on hardware implementations of crypto-functions...
cheers,
Spleen Splitter
------------------------------
** 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
******************************
