Cryptography-Digest Digest #760, Volume #12 Sun, 24 Sep 00 10:13:01 EDT
Contents:
Re: How many possible keys does a Playfair cipher have? (wtshaw)
Re: Encrypted File Systems..? (Paul Schlyter)
RSA occasional failure? (Mark-Jason Dominus)
Re: RSA occasional failure? (Paul Rubin)
Re: What make a cipher resistent to Differential Cryptanalysis? (Simon Johnson)
Re: PGP 6.5.8 source code published ("Our Man In K-Space")
Re: RSA occasional failure? (Paul Schlyter)
Re: Big CRC polynomials? (Tom St Denis)
Re: My attempt at an alogrithm. (Simon Johnson)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
Re: What make a cipher resistent to Differential Cryptanalysis? (Daniel Vogelheim)
Re: 128-bit Secure LFSR (Whoops) (Jeff Gonion)
Re: Encrypted File Systems..? (Jonathan Thornburg)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How many possible keys does a Playfair cipher have?
Date: Sun, 24 Sep 2000 01:20:06 -0600
In article <[EMAIL PROTECTED]>, David Empey
<[EMAIL PROTECTED]> wrote:
> Unless there's some other symmetry of the cipher none of us has thought
> of.
62) *Break majestic words into quizzical digraphs to encrypt vexing playfair.
--
A Pangram: 57) *The Codebreakers often views juxaposed
cryptological maze quests.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Encrypted File Systems..?
Date: 24 Sep 2000 09:56:13 +0200
In article <8qk0l9$j7h$[EMAIL PROTECTED]>,
halofive <[EMAIL PROTECTED]> wrote:
> Is the idea of a "secure filesystem" logical? I've been playing around
> with Linux (suse, in particular) and love it- but I'd like to know if
> this would sound logical to try:
>
> Create a small partition with the boot loader software and decryption
> alorithm- using something similar to DES or IDEA.
>
> Then, encrypt your entire partition file system (root etc).
> The only way to access would be to enter the correct password at the
> bootup, which would then decrypt the contents of the hard drive.
>
> Maybe I'm thinking out of my ass, the problems would be obvious.
> Where can I store the files as they're being decrypted?
> and
> Any files decrypted or downloaded would be saved on the disk- making
> the possibility of recovering the data stored on the disk possible.
You cannot store the decrypted files on some other place on the disk,
because if you do, they'll be available anyway to anyone trying to
bypass the decryption. And then you might as well not bother with
encrypting the disk.
If you want to add disk encryption like this, you'll have a decision
to make: should the disk be encrypted at the file system level, or
at some lower level?
If you encrypt the disk at the file system level, some info in the
partition will remain unencrypted. Then you'll also have the option
to encrypt only some of the files on the disk (you may want to do
that for e.g. performance reasons). To do this you must add the
crypto to the file system of the OS you're using.
If you encrypt the disk at some lower level, the entire partition
will be encrypted: root directory, subdirectories, files, free disk
space -- everything. This is both simpler and more complex than
adding enryption at the file system level: you add the crypto to
the block drivers of the disk, and need not worry about what should
be encrypted and what shouldn't. OTOH you need disk encryption also
during the boot phase of the system. If you're running Linux on a
PC, this means you must implement the disk encryption both in
real mode (e.g. integrated with the LILO) and protected mode.
The real mode disk crypto module is probably where you want the
user to enter his password, and this password must somehow be
passed on to the protected mode crypto module when it starts up.
In either case you'll have a performance issue to consider as well:
if you e.g. choose DES or 3DES as your encryption algorithm, you can
expect the disk I/O performance to be considerably degraded (unless
you intend to use a DES hardware chip), since DES, and 3DES even
more, is slow if implemented in software.
Finally, the encryption should somehow be made dependent on the
location on the disk of the data to be encrypted, or else identical
disk blocks will remain identical even after encryption, which is not
good from a security point of view. One way would be to obtain the
block number for each block to be en/decrypted, and then e.g. XOR key
with the the block number before using it for en/decryption.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
Subject: RSA occasional failure?
From: [EMAIL PROTECTED] (Mark-Jason Dominus)
Date: Sun, 24 Sep 2000 08:33:51 GMT
As I understand it, RSA depends on the fact that for suitable
generated d and e,
(x^e)^d = x (mod m)
where e is the public key and d is the secret key.
This follows from Fermat's theorem, because e and d have been
constructed so that ed = 1 + k(p-1)(q-1), and m=pq, where p and q are
primes. Then
(p-1)(q-1)
x = 1 (mod p)
and similarly for q.
But Fermat's theorem only applies in this case if x is not a multiple
of p; if x is a multiple of p then x^(p-1) (mod p) might be something
other than 1.
Since x is the plaintext, it is chosen by someone who doesn't know p
or q. It seems that if x unfortunately turned out to be a multiple of
p, then the decryption process would fail and yield a gibberish
result.
How is this avoided in practice? Or did I get something wrong?
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: RSA occasional failure?
Date: 24 Sep 2000 02:50:53 -0700
[EMAIL PROTECTED] (Mark-Jason Dominus) writes:
> But Fermat's theorem only applies in this case if x is not a multiple
> of p; if x is a multiple of p then x^(p-1) (mod p) might be something
> other than 1.
>
> Since x is the plaintext, it is chosen by someone who doesn't know p
> or q. It seems that if x unfortunately turned out to be a multiple of
> p, then the decryption process would fail and yield a gibberish
> result.
Since N=pq, the chance of a random x < N being a multiple of p is 1/q.
Since q is normally > 10^100, this probabilit is negligible. But
you're correct, if you pick some small primes (p=3, q=5) and try to
work an RSA example on the blackboard and choose the wrong x, you can
sometimes get bitten by this.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 10:32:37 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> "David C. Barber" wrote:
> >
> > DES, for example is considered resistant to Differential
Cryptanalysis,
> > particularly in its selection of S-boxes. What about them, or any
cipher,
> > makes it DF resistant?
>
> I believe that one good way is to arrage to have the
> S-boxes of the cipher be all different and to have
> them either key-dependent or fixed but having their
> ordering dependent on the key. I like to know references
> to analysis results for such situations, if any.
>
> M. K. Shen
> -----------------------
> http://home.t-online.de/home/mok-kong.shen
>
I don't see how an s-box can have its structure dependent on the key
without a probability of producing very poor s-boxes. Is this an
accepted risk or do they use some fool proof transformation.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Our Man In K-Space" <h|@planetquake.com>
Subject: Re: PGP 6.5.8 source code published
Date: Sun, 24 Sep 2000 12:20:13 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
ftp://ftp.zedz.net/pub/crypto/pgp/pgp60/source/pgpsrc658win32.zip
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.8
iQA/AwUBOc3jbDYtWvgjE/QgEQL7XQCgmYXLQVt/h9SMfEoOVE0hgJzhFFMAoNxc
3WDFet0zQBM0y49wgvg9/E8P
=xv4G
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: RSA occasional failure?
Date: 24 Sep 2000 12:40:48 +0200
In article <39cdbc6f.1d8d$[EMAIL PROTECTED]>,
Mark-Jason Dominus <[EMAIL PROTECTED]> wrote:
> As I understand it, RSA depends on the fact that for suitable
> generated d and e,
>
> (x^e)^d = x (mod m)
>
> where e is the public key and d is the secret key.
>
> This follows from Fermat's theorem, because e and d have been
> constructed so that ed = 1 + k(p-1)(q-1), and m=pq, where p and q are
> primes. Then
>
> (p-1)(q-1)
> x = 1 (mod p)
>
> and similarly for q.
>
> But Fermat's theorem only applies in this case if x is not a multiple
> of p; if x is a multiple of p then x^(p-1) (mod p) might be something
> other than 1.
>
> Since x is the plaintext, it is chosen by someone who doesn't know p
> or q. It seems that if x unfortunately turned out to be a multiple of
> p, then the decryption process would fail and yield a gibberish
> result.
Lemme see here --- let's pick p=11 and q=13 ==> N=143 and phi=120
Let's choose e=17, which yields d=113
Now let's pick x = k*p, say x = 55
55^17 mod 143 = 22
22^113 mod 143 = 55
and
55^113 mod 143 = 22
22^17 mod 143 = 55
So it doesn't seem to yield a gibberish result, however both the
secret and the public key here seem to produce the same result after
exponentiation. Which would mean one can use the public key as well
as the secret key, and in effect there would be no secret anymore.
> How is this avoided in practice? Or did I get something wrong?
It's probably not avoided at all, since the probability of this
happenning is extremely small -- about as small as the probability
of this happening:
In RSA, N = p*q, and if either p or q get to be known, the encryption
is broken. Now if someone happens to guess the correct p, or q, he
can find out the secret RSA key from the public key. How is this
avoided in practice? :-)
The answer is the same in both cases: one doesn't bother avoiding it
but instead rely in the probability of it happening being extremely
small.
Consider a 768-bit RSA encryption (the minimum RSA key size now
recommended for safe RSA encryptions, since a 512-bit modulus has
been successfully factored). p and q will be 384 bits each, and
their numerical values will be of the order of magnitude of 4E+115
which is a quite big number.
Now, suppose each and every citizen of the Earth were doing one
billion (1E+9) RSA encryptions each and every second, 24 hrs/day
365 days/year, year after year. How long would it take before one
of them, by accident, had a cleartext which was an even multiple
of p, or q. Probabilistically, this could be expected approximately
when 4E+115 encryptions had been performed. How long would this
take? It would take:
4E+115 / 5E+9 / 1E+9 / 86400 / 365 = 2.5E+89 years
which is an extremely long time, approximately 1E+80 times longer than
the currently accepted value of the age of the universe.
So I don't think you need to worry about this happening very soon... :-))))
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Sun, 24 Sep 2000 11:25:02 GMT
In article <kTdz5.4621$[EMAIL PROTECTED]>,
"bubba" <[EMAIL PROTECTED]> wrote:
> Try this experiment on a scaled down example. Use CRC, use checksum.
> Evaluate ALL files. Obviously the results will be equal, because each
check
> code aliases to the same number of different files. It is not really
that
> hard.
> Maybe I will write a program to demonstrate.
A CRC is more reliable then simple "summing" checksums, I don't care
how you put it. Burst errors are what CRC's detect and 99.99% they
catch them. I don't care much for maticulous manipulation of the file,
I mean sure given enough time I could fake out md5....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: My attempt at an alogrithm.
Date: Sun, 24 Sep 2000 11:22:40 GMT
In article <8q92lu$24i$[EMAIL PROTECTED]>,
halofive <[EMAIL PROTECTED]> wrote:
> hello, I'm sorry if this is the wrong place to post ideas...
>
> lately i've been reading a book concerning cryptography and it's had
me
> thinking about ways to encrypt files. Can someone please tell me if
my
> idea is efficient? I'm going to start writing it in C- but I would
like
> too see if anyone has any suggestions.
>
> -=-=-=-
>
> The program requires the user to first input the password being used
> (key). The program breaks down the password (starting from the end
> working to the first letters input).
>
> Multiplying the last letter's [of the the password] ascii value, plus
> two, by the ascii value of each char's ascii value, divided by ten,
> results in the first chars encrypted value (represented in ascii).
>
> This is done individually with each char of the password, on each new
> encrypted char- over and over.
>
> -=-=-=-
If one input character equals 0 the hash output will equal 0. One
question, are you doing you're multiplications, division and additions
mod 256?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 11:26:17 GMT
In article <8qkl86$8m7$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >
> > "David C. Barber" wrote:
> > >
> > > DES, for example is considered resistant to Differential
> Cryptanalysis,
> > > particularly in its selection of S-boxes. What about them, or any
> cipher,
> > > makes it DF resistant?
> >
> > I believe that one good way is to arrage to have the
> > S-boxes of the cipher be all different and to have
> > them either key-dependent or fixed but having their
> > ordering dependent on the key. I like to know references
> > to analysis results for such situations, if any.
> >
> > M. K. Shen
> > -----------------------
> > http://home.t-online.de/home/mok-kong.shen
> >
>
> I don't see how an s-box can have its structure dependent on the key
> without a probability of producing very poor s-boxes. Is this an
> accepted risk or do they use some fool proof transformation.
No, consider my fav function "f(x) = a.x + b" the derivative of which
is merely "a". This is weak in the eyes of differential cryptanalysis
if you know "a" but think about it if you don't.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Daniel Vogelheim <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 15:01:24 +0200
Hello sci.crypt & Mok-Kong,
Mok-Kong Shen wrote:
>I believe that one good way is to arrage to have the
>S-boxes of the cipher be all different and to have
>them either key-dependent or fixed but having their
>ordering dependent on the key. I like to know references
>to analysis results for such situations, if any.
Siemens apparently has a (patent-pending) DES implementation that
applies the S-boxes in randomized order.
I understand your idea as trying to make general cryptanalysis harder
by using changing S-boxes as a cryptographic primitive. In contrast,
the Siemens patent application refers to computation of the well-known
DES algorithm, but changing the order of computation to level out the
power profile, i.e. as a protection against (differential) power
analysis. They change the implementation to thwart side-channel
attacks, rather than change the algorithm to prevent "normal"
cryptanalysis.
References:
[1] IBM patent server, DE19845073A1
[2] DEPAnet, DE19845073
Two related questions:
1) This is the first serious attempt I know of to harden
implementations against power analysis attacks. Anyone else knows
others?
2) Is there any security difference in using multiple S-boxes per
round vs. using different S-boxes in different rounds? I'm thinking of
DES vs. Serpent here: DES applies eight different S-boxes within each
round and all rounds are the same. Serpent applies the same S-box in
each round, but the rounds are different. This makes Serpent faster;
but what about security?
Sincerely,
Daniel Vogelheim
------------------------------
Date: Sun, 24 Sep 2000 08:41:43 -0500
From: [EMAIL PROTECTED] (Jeff Gonion)
Subject: Re: 128-bit Secure LFSR (Whoops)
Tom,
I didn't look at your polynomial, but the first thing I noticed is that
your LFSR code seems to be incorrect. You need to shift EVERY time through.
The code on your website appears only to shift if the LSB is 0.
> if (m[0] & 1) {
> m[3] ^= 0xf7c4fe2aul;
> m[2] ^= 0x3cbc11fbul;
> m[1] ^= 0x49c35ed1ul;
> m[0] ^= 0xbbcc1888ul;
> r = 1;
> } else
> r = 0;
> m[0] = (m[0]>>1)|(m[1]<<31);
> m[1] = (m[1]>>1)|(m[2]<<31);
> m[2] = (m[2]>>1)|(m[3]<<31);
> m[3] = (m[3]>>1)|(r<<31);
> return r;
Also, you should never need to shift anything more than once.
Rather than shifting all of the m[]<<31, all you need to do is
reverse the direction of every other m[]. After all, all you care
about is the 1-bit output, and the 1-bit that propagates between
stages. Try this (I haven't tested it, it's off the top of my head):
> register unsigned r;
>
> r = m[0] & 1;
> m[0] = (m[0]>>1)|(m[1]&0x80000000);
> m[1] = (m[1]<<1)|(m[2]&1);
> m[2] = (m[2]>>1)|(m[3]&0x80000000);
> m[3] = (m[3]<<1);
> if (r)
> m[0] ^= kXORMASK0;
> m[1] ^= kXORMASK1Reversed;
> m[2] ^= kXORMASK2;
> m[3] ^= kXORMASK3Reversed;
> return r;
Hope this helps...
- Jeff
P.S. - I've got a PDF paper that explains LFSR's pretty well, in
everyday english, including Golumb�s criteria for randomness,
modulo-2 polynomial math, and The Berlekamp-Massey algorithm,
which is used to determine the shortest LFSR that can produce
a given bitstream. If anyone would like a copy, I can email it,
since this newsgroup doesn't seem to accept binaries.
================================================================
In article <8qjaqg$rut$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> I reposted my slfsr to my website at
>
> http://www.geocities.com/tomstdenis/files/slfsr.c
>
> I am using a single 128-bit LFSR in self-shrinking mode. I would
> appreciate someone who could verify the polynomial used. I am using
> the LFSR in galois config. I made the LFSR poly with a program called
> LFSR.EXE that I found on an ftp that was posted here a bit ago.
>
> It's compact code, albeit not that efficient (are any LFSR's
> efficient?). It features a simple rekeying :), fast enough for desktop
> usage and it's really simple...
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Encrypted File Systems..?
Date: 24 Sep 2000 15:50:30 +0200
halofive <[EMAIL PROTECTED]> wrote:
>Is the idea of a "secure filesystem" logical? [[...]]
>
>Then, encrypt your entire partition file system (root etc).
>The only way to access would be to enter the correct password at the
>bootup, which would then decrypt the contents of the hard drive.
In article <[EMAIL PROTECTED]>,
Ken Y. Ramoil <[EMAIL PROTECTED]> wrote:
>You could model it around Scramdisk. That's a popular on-the-fly disk
>encryption program with open source: http://www.scramdisk.clara.net/
>or you could find several references to other similar programs here:
>http://www.fortunecity.com/skyscraper/true/882/index.htm
>
>I don't know if any such programs already exist for Linux.
Matt Blaze's Cryptographic File System works very nicely on Linux
(along with a great many other Unix platforms).
He published a description of it way back in 1993
M. Blaze.
"A Cryptographic File System for Unix."
Proceedings of the First ACM Conference on
Computer and Communications Security, Fairfax, VA,
November 1993.
http://www.crypto.com/papers/cfs.ps
(see also http://www.crypto.com/papers/cfskey.ps )
and released the source code within the USA and Canada.
Quoting from http://www.crypto.com/papers/cfs.announce ,
> Source code for the latest version (1.4.0BETA) of CFS, the Cryptographic
> File System, is now available upon request for research and experimental
> use in the US and Canada. This version works under most BSD-derived Unix
> systems and should now run without modification under most current Linux
> releases as well.
>
> CFS pushes encryption services into the Unix(tm) file system. It
> supports secure storage at the system level through a standard Unix
> file system interface to encrypted files. Users associate a
> cryptographic key with the directories they wish to protect. Files in
> these directories (as well as their pathname components) are
> transparently encrypted and decrypted with the specified key without
> further user intervention; cleartext is never stored on a disk or sent
> to a remote file server. CFS employs a novel combination of DES
> stream and codebook cipher modes to provide high security with good
> performance on a modern workstation. CFS can use any available file
> system for its underlying storage without modification, including
> remote file servers such as NFS. System management functions, such as
> file backup, work in a normal manner and without knowledge of the key.
>
> CFS runs under SunOS and several other BSD-derived systems with NFS.
> It is implemented entirely at user level, as a local NFS server
> running on the client machine's "loopback" interface. It consists of
> about 5000 lines of code and supporting documentation. You must have
> "root" access to install CFS.
This document goes on to describe how you can get cfs.
Up until recently, US laws forbade the free export of cfs and other
such cryptographic software. However, some copies did leak out... you
could probably find several by asking your favorite web search engine
to look for cfs.1.4.0.beta2.tar.gz .
I don't know if cfs is now more freely available.
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Q: Only 7 countries have the death penalty for children. Which are they?
A: Congo, Iran, Nigeria, Pakistan[*], Saudi Arabia, United States, Yemen
[*] Pakistan moved to end this in July 2000. -- Amnesty International,
http://www.amnesty.org/ailib/aipub/2000/AMR/25113900.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 13:53:19 GMT
In article <[EMAIL PROTECTED]>,
Daniel Vogelheim <[EMAIL PROTECTED]> wrote:
> Hello sci.crypt & Mok-Kong,
>
> Mok-Kong Shen wrote:
> >I believe that one good way is to arrage to have the
> >S-boxes of the cipher be all different and to have
> >them either key-dependent or fixed but having their
> >ordering dependent on the key. I like to know references
> >to analysis results for such situations, if any.
>
> Siemens apparently has a (patent-pending) DES implementation that
> applies the S-boxes in randomized order.
>
> I understand your idea as trying to make general cryptanalysis harder
> by using changing S-boxes as a cryptographic primitive. In contrast,
> the Siemens patent application refers to computation of the well-known
> DES algorithm, but changing the order of computation to level out the
> power profile, i.e. as a protection against (differential) power
> analysis. They change the implementation to thwart side-channel
> attacks, rather than change the algorithm to prevent "normal"
> cryptanalysis.
>
> References:
> [1] IBM patent server, DE19845073A1
> [2] DEPAnet, DE19845073
>
> Two related questions:
>
> 1) This is the first serious attempt I know of to harden
> implementations against power analysis attacks. Anyone else knows
> others?
Better hardware?
>
> 2) Is there any security difference in using multiple S-boxes per
> round vs. using different S-boxes in different rounds? I'm thinking of
> DES vs. Serpent here: DES applies eight different S-boxes within each
> round and all rounds are the same. Serpent applies the same S-box in
> each round, but the rounds are different. This makes Serpent faster;
> but what about security?
Um considering the fact that all the differences occur in parallel yeah
it's very bad in fact all of the bits in parallel are linearly
correlated. However, (big however) the linear mixing phase of Serpent
ensures that such parallisms do not hold with high probability at all.
Obviously parallel distinct independent sboxes would be better for
serpent but at a huge cost in performance and you *still* need the
diffusion step. So Serpent is a very sound and careful design.
Tom
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
******************************
