Cryptography-Digest Digest #74, Volume #13 Thu, 2 Nov 00 12:13:00 EST
Contents:
Re: Give it up? (Richard Heathfield)
Beale Cypher (Set'em up Joe)
F-Secure File Crypto uses ECB (Markku-Juhani Saarinen)
Re: Give it up? (SCOTT19U.ZIP_GUY)
Re: index of coincidence of Spanish/Turkey ("John A. Malley")
Re: Beale Cypher (JPeschel)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: Give it up? (James Felling)
Re: Give it up? (Alfons Adriaensen)
Re: Give it up? (CiPHER)
Re: is NIST just nuts? (Mehdi-Laurent Akkar)
Re: Hardware RNGs (Alan Rouse)
Re: BENNY AND THE MTB? ("Brian Gladman")
Re: Psuedo-random number generator (Alan Rouse)
Lisp! (Re: Emacs hack for OpenSSL encryption) (Sundial Services)
Re: Psuedo-random number generator (Alan Rouse)
Re: Psuedo-random number generator (Alan Rouse)
Re: Give it up? (Richard Heathfield)
Re: Newbie about Rijndael (Bob Deblier)
----------------------------------------------------------------------------
Date: Thu, 02 Nov 2000 13:21:53 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Tom St Denis wrote:
>
> >
> > Tom - you probably already know this, but I'll say it anyway:
> >
> > #include "iamnotacryptographer.h"
I left this bit in as a reminder. :-)
> > Now, let's take a specific example: PKZIP. If Z is the compression
> > function, then C = E(Z(P)).
> >
> > Since PKZIP'd headers begin with the two octets 0x504B ("PK" in
> ASCII),
> > we have a known plaintext attack against E(), do we not? I know two
> > octets isn't much, but it's the /first/ two octets, which probably
> helps
> > somewhat.
> >
> > Do you see my difficulty?
> >
> > (It could be argued, perhaps, that one could prevent this attack by
> > using a 'headerless' algorithm, such as RLE.)
>
> So what? I could give you a terabyte of known plaintext and you
> couldn't guess the key or plaintext (assuming the known plaintext and
> the original plaintext message are not the same (or a subset)).
But it /is/ a subset (because, from the point of view of breaking E(),
Z(P) is the plaintext). The known plaintext is (in the case of PKZIP)
"PK", and not only is it known but also its location is known. I'm just
suggesting that it reduces Eve's evaluation effort if she can discard a
possible plaintext if the first two octets aren't "PK" (in this
example).
>
> Even knowing two bytes of one block is not sufficient to get a single
> known plaintext (assuming the block size is larger then 16-bits).
I don't think I was suggesting it was. I was suggesting that the work
involved in breaking the key would be reduced.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED] (Set'em up Joe)
Subject: Beale Cypher
Date: Thu, 02 Nov 2000 14:07:46 GMT
Looking for current opinions of ng on Beale, real vs. hoax.
TIA,
Andrew
------------------------------
From: Markku-Juhani Saarinen <[EMAIL PROTECTED]>
Subject: F-Secure File Crypto uses ECB
Date: Thu, 2 Nov 2000 14:25:11 +0000 (UTC)
>From a reliable source:
The File Crypto product ( http://www.f-secure.com/products/filecrypto/ )
from F-Secure apparently uses the electronic code book (ECB) mode of
operation to encrypt files.
This obviously makes encrypted low-entropy data (e.g. uncompressed
bitmaps or sound files, plain ascii text) vulnerable to codebook attacks
regardless of key size or encryption algorithm used.
Cheers,
- mj
Markku-Juhani O. Saarinen <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Give it up?
Date: 2 Nov 2000 14:47:45 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
>Tom St Denis wrote:
>>
><snip>
>>
>> Unless their attacks break the cipher when the input is redundant ASCII
>> there is no security advantage to using contrived inefficient codecs
>> instead of something good like bzip or deflate.
>
>
>Tom - you probably already know this, but I'll say it anyway:
>
>#include "iamnotacryptographer.h"
>
>Right, now that we understand each other, I have some difficulty with
>using compression to enhance encryption, which you could perhaps explain
>to me...
>
>Firstly, we can agree, I think that (a) the compression is part of the
>algorithm, and (b) we must assume that Eve knows the algorithm.
>
>Now, let's take a specific example: PKZIP. If Z is the compression
>function, then C = E(Z(P)).
>
>Since PKZIP'd headers begin with the two octets 0x504B ("PK" in ASCII),
>we have a known plaintext attack against E(), do we not? I know two
>octets isn't much, but it's the /first/ two octets, which probably helps
>somewhat.
>
>Do you see my difficulty?
>
>(It could be argued, perhaps, that one could prevent this attack by
>using a 'headerless' algorithm, such as RLE.)
>
>
I could not resist jumping in. Most implementation of RLE
are very very bad. Since they allow many of the possible forms
of a compressed file to map to the original source file. Example
you may compress aaaaaa to something like aa<4> but the
decompressor witten for it may not only decompress aa<4> to
6 a's but it would also decompress aa<1>aa<1> to 6 a's. This
means that if you test a key and see aa<1>aa<1> in the text
you know you used the wrong key since when its decompressed the
file it decompresses to would not create that file when it compresses
so the aa<1>aa<1> is not a possible compression from the RLE in use.
THis is exactly this sort of error in BZIP2. THe funny thing is that
its easy to fix such schemes so that the compressed output will always
be the same size or smaller. THe fix is not rocket science.
Most can see many of the obvious header errors as being a mistake
but most fail to see beyond that. YOu'll get there yet. Also I don't
hate MOK it just our discussions get in endless loops. Maybe if we
sat down over a few beers and had faster turnaround we could get some
where but not here.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: index of coincidence of Spanish/Turkey
Date: Thu, 02 Nov 2000 06:59:19 -0800
[EMAIL PROTECTED] wrote:
>
> Do you know the IC of Spanish and Turkey?
> Are my values correct?
> german IC=0.0762
> english IC=0.0658
> french IC=0.0778
Bauer lists indices of coincidence for seven languages in Chapter 16,
Section 1 of his book "Decrypted Secrets, Methods and Maxims of
Cryptology."
English 26 characters 6.61%
German 26 characters 7.62%
French 26 characters 7.78%
Italian 26 characters 7.38%
Spanish 26 characters 7.75%
All values from a source named Kullback, 1976.
In the text of section 16.1 he provides information on the variability
of the IC as a function of text type.
In German literature the IC may vary from 7.5 - 8.3% and in English
literature the IC may vary from 6.5 - 6.9%.
>From a text corpus of 4 million characters of English text, by
Meyer-Matyas, the IC value for English is 6.58% (your figure) and a
corpus of German text dubbed SZ3-92, some 681,972 characters of text,
the IC is 7.62% (your figure)
Found nothing on Turkish. Maybe it can be extrapolated from a
relationship with another language? But - if memory serves, Turkish is
not a member of the Indo-European language family.
Hope this helps,
John A. Malley
[EMAIL PROTECTED]
> thanx
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Beale Cypher
Date: 02 Nov 2000 15:01:40 GMT
[EMAIL PROTECTED] writes:
>Looking for current opinions of ng on Beale, real vs. hoax.
Jim Gillogly wrote his opinion in Cryptologia in April 1980.
http://members.fortunecity.com/jpeschel/gillog3.htm
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 2 Nov 2000 14:58:34 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
snip
>If I understand you correctly here, then my confusion is resolved. There
>are, indeed, only 256 possible messages for one octet, when the key is
>fixed. If the key is not known then, of course, those 256 bit patterns
>could be hooks into any message at all. I understood that before. It
>would appear, then, that there is no ambiguity after all.
I am not sure what you mean by "hooks". for any key it maps to 256
different messages none of which in that set are the same. It also highly
on likely that for a thousand test keys that any of the decyrpted messages
would be the same.
>
><snip>
>
>> It seems strange only because people have been expertly
>> psychologically conditioned to do compression and encryption
>> the wrong way so that groups like the NSA remain in control
>> and can break and read your code. I don't think Im smarter
>> than every one else. Many its the way my brain operates that
>> has given me partial immunity to this expert conditioning.
>> That has so much seemed to have inflected havic on the
>> open crypto community. It is so good that the misinformation
>> spreads just like a cult religon. Look at Tommy and the crap
>> he spreads I think he actually means well but he has this
>> software brain virus in a bad way I think.
>
>Right up until this paragraph, I was thinking "Good Lord, Mr Scott has
>actually written an intelligent and informative reply". It is a great
>shame that you had to spoil it with misplaced paranoia and ad hominum
>attacks.
Actaully if I did not add something like the above some people
might buy into what I have said without thinking. I don't want that
its not fair. Besides some people like to see a little color.
Wouldn't you like to see a speaker like me at a compression conference.
I bet your hooked enough to attend. But since I think most conferences
are only to pat the chossen on the back you will not see me there.
I did dream I was invited. And told my wife I would wear the same
colthes I wear when I use to go DC on travel but she frowned on that she
doesn't like my taste in clothes and I think she is secrestly destroying
all my old well figthed clothes so that I may not be able to stand out
as well. I think she tossed out my favorite green T sheet with holes
I wore it for years at work.
>
>Nevertheless, I thank you for confirming that I had merely misunderstood
>the context in which you were claiming > 256 messages for one octet.
>
>
YOur welcome I think.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Thu, 02 Nov 2000 09:10:51 -0600
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >
> > Tom St Denis wrote:
> > >
> >
> > > Um it's rather obvious what my point is. "Security != codec". i.e,
> get
> > > your security from ciphers and cryptography and not from a huffman
> > > codec.
> > >
> > > If you can't comprehend this... well too bad.
>
> <snip>
>
> The word "codec" is used quite often in compression groups because it
> refers to "COmpression DECompression engine". Somies to "COding
> DECoding" as well...
>
> I don't see how compressing a message can make it any more random (i.e
> less redundant) then it already is.
Compression cannot make it more random, but compression typically will make
it less redundant.( Thats effectively how compression works)
>
>
> Unless their attacks break the cipher when the input is redundant ASCII
> there is no security advantage to using contrived inefficient codecs
> instead of something good like bzip or deflate.
Agreed with reservations here. There are benefits to a 1-1(bijective)
compressor vs. the alternative, however the most important crireria are how
effectively it compresses the data, and how 'artifact' free it is. After
choosing on that basis, I'd take a bijective method vs a non-bijective
method.
Reasoning.
1) Artifacts are a big weakness as to compression -- they allow efficient
recognition of "valid" plaintext vs. random garbage -- this speeds key
testing ( necessary in almost any attack) vs. less artifact prone methods.
In addtion they can be used as a form of 'likely plaintext' in actually
attacking the cypher.
2) efficient compression serves to inhibit attacks if only by increasing
the effective unicity distance, and also by reducing the amount of data
sent -- this has the effect of giving the opponent a lesser chance of
having enough data to pursue a particular attack
3) bijectivity also lengthens the unicity distance, ( effecitvely by
increasing the space of possibly valid cyphertexts -- yes once they
decompress they may be discarded as useless, but this does force
decompression)
>
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Alfons Adriaensen)
Subject: Re: Give it up?
Date: 02 Nov 2000 15:03:50 GMT
In article <[EMAIL PROTECTED]> Richard Heathfield
<[EMAIL PROTECTED]> writes:
> > Even knowing two bytes of one block is not sufficient to get a single
> > known plaintext (assuming the block size is larger then 16-bits).
>
> I don't think I was suggesting it was. I was suggesting that the work
> involved in breaking the key would be reduced.
If E() is any good, even millions of corresponding P/C blocks wouldn't help
you to reduce the work required to recover the key.
So the "PK" problem doesn't exist in practice.
--
Fons
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Thu, 02 Nov 2000 15:23:57 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > The word "codec" is used quite often in compression groups because
> > refers to "COmpression DECompression engine". Somies to "COding
> > DECoding" as well...
> However you should consider that not everybody subscribes
> to the other groups and the same shorthand may have different
> meaning in different disciplines. (I saw e.g. DES with
> an entirely different meaning elsewhere.)
Well, _I_ know what codec means and I ain't no fancy-dancy
crypto/compression god. You mean to tell me you've never used a media
playing program? Their set-up menus, help files and text files are
filled with mentions of codecs.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mehdi-Laurent Akkar <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: is NIST just nuts?
Date: Thu, 02 Nov 2000 15:44:39 GMT
Now most of the smart card processor have a DES processor or at least DES
acceleration instruction
(Philips, ST, Infineon ...)
MLA
Shawn Willden a �crit :
> Tim Tyler wrote:
>
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > : Albert Yang <[EMAIL PROTECTED]> wrote:
> >
> > :> It wasn't the fastest on hardware (Serpent, Rijndael)
> >
> > : Hardware is *not* where we will see alot uses of it.
> >
> > I thought that was a pretty central design consideration.
> >
> > AES will be used in smart cards and the like.
>
> AES will not be implemented in hardware on smart cards, just as DES is
> not. For smart cards the relevant question is how an algorithm performs
> in software on simple 8-bit architectures.
>
> Shawn.
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Thu, 02 Nov 2000 15:43:41 GMT
Hashing does not increase entropy, whether one pass or multiple.
If the input comes from a population of x equally probable values,
there will be exactly x equally probable outputs from a strong hash
function. If the probabilities of the possible inputs are not equal,
then the entropy is reduced. (An attacker can attack the most probable
inputs first. The expected number of trials to find the actual input
value would be less than half of x).
If the number of repetitions of the hash function varies randomly then
that would add a bit or two of entropy... but if the number of
repetitions is deterministic then it adds no entropy.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Thu, 2 Nov 2000 15:58:22 -0000
<[EMAIL PROTECTED]> wrote in message
news:8tqatk$slb$[EMAIL PROTECTED]...
>
>
> "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > : Tim Tyler wrote:
> [snip]
> > Matt's code takes a message, compresses it, maps the result to
> > a 128-bit granular file, encrypts it, and maps the result to
> > an 8-bit granular file.
>
> Actually that clarified the issue. Correct me if I'm wrong, but what
> matt has done is taken a file, compressed it, encrypted it, and (de)
> compressed it (I'm a little hazy on whether the last step should be
> considered compression or decompression).
It really isn't either of these. In basic terms the last two 16 byte blocks
are handled in a particular way. The first of these is encrypted with a CBC
from the previous block to give a ciphertext block. If the second (i.e. the
last block in the file) has N valid bytes then N bytes of this ciphetext are
output and another 16 byte block is formed by appending the last N bytes of
the file to the remaining 16 - N bytes of this ciphertext. This block is
then encrypted (using the same CBC value) and output.
In fact, this is an over simplified description since the method also deals
with a last byte that contains less than 8 valid bits so that the
transformation never operates on any 'non message' bits.
Whether this way of treating the file ending is significantly better in
security terms than other ways (such as various forms of padding) is subject
to debate. If you believe Mr Scott the answer is 'yes'; if you believe
others in the professional cryptographic community the answer is 'no'.
Brian Gladman
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Thu, 02 Nov 2000 16:09:20 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
> Who said anything about being balanced or having exactly maximal
> entropy? I'm talking about having sufficient entropy for cryptographic
> purposes, nothing more, nothing less
How much entropy is sufficient? Enough to support the design criteria
of the encryption. Presumably a cryptosystem designer would select the
key size, such that the size of the brute force attack would be
sufficiently large--that is, above some design threshold.
Assuming a brute force attack on a key consisting of n truly random
bits (each bit being an independent event, having exactly equal chances
of being 1 or zero), the expected number of trials is n/2. But if the
key doesn't meet those criteria, the expected number of trials may be
less. An attacker who understands the weakness in the randomness of
the key generation process can optimize his search by trying the most
likely values first, which will lower the expected number of trials
below n/2.
Obviously hashing has no impact on the expected number of trials. If
there are only x (x < n) possible seed values, then there will be only
x possible outputs from the hash function, and only those x hash values
must be searched by the attacker.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 02 Nov 2000 09:24:56 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Lisp! (Re: Emacs hack for OpenSSL encryption)
Well I'll be ... a genuine "LISP program in-the-wild." Never saw one
before.
>David Rush wrote:
>
> Also, ssl-hacks.el now lives at
> http://cryptognome.sourceforge.net/ssl-hacks.el
>
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Thu, 02 Nov 2000 16:16:31 GMT
oops, not n/2, but 2^(n-1).... duh
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Thu, 02 Nov 2000 16:24:29 GMT
There is probably some useful entropy in background noise. The
difficulty is in knowing how much entropy you are getting. Perhaps you
could take the LSB of each byte, maybe the two LSB's... But you would
need to evaluate the amount of entropy to be sure.
The best way I know to do that is to generate about 2.9 million
supposedly-random 4-byte large integers bit-by-bit, then run them
through the Diehard tests (see http://stat.fsu.edu/~geo/diehard.html).
That might give you a decent level of confidence, if your sample
manages to pass the tests.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 02 Nov 2000 16:40:58 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Give it up?
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
>
> >Tom St Denis wrote:
> >>
> ><snip>
> >>
> >> Unless their attacks break the cipher when the input is redundant ASCII
> >> there is no security advantage to using contrived inefficient codecs
> >> instead of something good like bzip or deflate.
> >
> >
> >Tom - you probably already know this, but I'll say it anyway:
> >
> >#include "iamnotacryptographer.h"
> >
> >Right, now that we understand each other, I have some difficulty with
> >using compression to enhance encryption, which you could perhaps explain
> >to me...
> >
> >Firstly, we can agree, I think that (a) the compression is part of the
> >algorithm, and (b) we must assume that Eve knows the algorithm.
> >
> >Now, let's take a specific example: PKZIP. If Z is the compression
> >function, then C = E(Z(P)).
> >
> >Since PKZIP'd headers begin with the two octets 0x504B ("PK" in ASCII),
> >we have a known plaintext attack against E(), do we not? I know two
> >octets isn't much, but it's the /first/ two octets, which probably helps
> >somewhat.
> >
> >Do you see my difficulty?
> >
> >(It could be argued, perhaps, that one could prevent this attack by
> >using a 'headerless' algorithm, such as RLE.)
> >
> >
>
> I could not resist jumping in. Most implementation of RLE
> are very very bad. Since they allow many of the possible forms
> of a compressed file to map to the original source file. Example
I was not advocating RLE as a compression algorithm. It has other
problems apart from cryptographic ones. I was simply pointing out that
it would not necessarily be susceptible to the attack under discussion.
<snip>
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Newbie about Rijndael
Date: Thu, 02 Nov 2000 17:53:23 +0100
mac wrote:
> Hello!
>
> I'm a newbie with Rijndael, block ciphers and cryptology in general. I've
> downloaded Mike Scott's C implementation from Rijndael's home site. I'm
> trying to figure out how it works and I have one question. When I want to
> encrypt a string of, say three characters(bytes), what do I have to fill up
> the rest of the array(another 14 bytes). I had problems when passing just a
> null terminated string that is much shorter that 16 bytes to encrypt/decrypt
> block functions. It works fine when I pass a 16-byte long null terminated
> array. I know this seems pretty dumb question to you, but I don't understand
> everything what's happening in encryption/decryption functions and it's
> killing me.
>
> Thank you very much for any explanations, thoughts or code.
On http://www.rsalabs,com, find the document describing PKCS#5; it offer a
method for padding and unpadding data blocks. If I recall correctly, the
document describes this method for a blockcipher with a block length of 8
bytes, but the method can easily be extended to 16 byte blocks:
Sincerely
Bob Deblier
Virtual Unlimited
------------------------------
** 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
******************************
