Cryptography-Digest Digest #856, Volume #13 Sat, 10 Mar 01 22:13:01 EST
Contents:
Re: Noninvertible encryption ("Todd Lewis")
Re: Q: Tempest Systems (Fred)
How to extract data from PC2.3 smartcard? ("P.Schurman")
Re: Using SHA as a checksum... ("Tom St Denis")
Re: Noninvertible encryption ("Amethyste")
Re: Super strong crypto (David Wagner)
Re: Safe to use DSS key for DH? (David Wagner)
Re: The Foolish Dozen or so in This News Group ("Trevor L. Jackson, III")
Re: Digital enveloppes - Off Topic (Mok-Kong Shen)
Re: Schneier's cryptanalysis self-study course ("Kostadin Bajalcaliev")
Re: Why do people continue to reply to Szopa? ("Dan Beale")
Re: Text of Applied Cryptography .. do not feed the trolls ("Dan Beale")
Re: Text of Applied Cryptography .. do not feed the trolls ("Tom St Denis")
Re: Text of Applied Cryptography (John Savard)
Re: Noninvertible encryption (Fred Galvin)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: Really simple stream cipher (Thomas Wu)
Re: Safe to use DSS key for DH? (DJohn37050)
----------------------------------------------------------------------------
From: "Todd Lewis" <[EMAIL PROTECTED]>
Subject: Re: Noninvertible encryption
Date: Sat, 10 Mar 2001 22:16:39 GMT
"John R Ramsden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Didn't they also use sticks or cones, around which a strip of parchment
> were wrapped before messages were written on it, and then those messages
> could later only be read back after wrapping the parchment on a shape of
> the same size?
At last, a question I can actually answer with confidence. :)
The Greeks used this form of encryption. The device to which you refer was
called a "scytale," and the message was deciphered when the parchment (more
appropriately, a leather strip) was wrapped around another scytale having
the same diameter.
I knew that reading "The Codebreakers" was going to pay dividends!
Very respectfully,
Todd Lewis
------------------------------
From: Fred <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: Tempest Systems
Date: Fri, 09 Mar 2001 17:38:07 -0500
Hello,
There is the unofficial Tempest informations page.
http://www.eskimo.com/~joelm/tempest.html
tempest is a old technology based on emanation monitoring ( electromagnetic
emanation by your cathodic monitor ).
Salutations,
Fred
------------------------------
Date: Sat, 10 Mar 2001 23:59:51 +0100
From: "P.Schurman" <[EMAIL PROTECTED]>
Subject: How to extract data from PC2.3 smartcard?
Hi,
I wonder if there is a way to extract data from a PC2.3 smartcard.
It should be pirat proof like other Bull smartcards.
When I use smartcardreader I only got some information about smartcard
and no data.
Regards,
Peter.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Using SHA as a checksum...
Date: Sat, 10 Mar 2001 23:22:01 GMT
"Moritz Voss" <[EMAIL PROTECTED]> wrote in message
news:98e685$1ia$06$[EMAIL PROTECTED]...
> > Well I wouldn't truncate the result to 32-bits though.
>
> No, I'd use it as a 160 bit CRC, /along/ with other purposes, so
essentially
> the data is also the 'key'...
>
> > You can't authenticate it unless the original is private.
>
> Hmm? What do you mean by this?
I mean I could make a virus script/program/whatever, associate a valid sha
hash with it. Then your system will run it.
I mean your programs/scripts that you associate must be private programs...
Tom
------------------------------
From: "Amethyste" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Sat, 10 Mar 2001 23:22:06 GMT
a non invertible transformation has some drawback like this
"do you mean"
becoming after adding (randomly) n e r i n g
"done your meaning"
and it is not the worse example I could find ...
definitively a cryptosystem *must* be invertible
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 10 Mar 2001 23:58:42 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>We need a *science* here, which is likely to have a strong
>"engineering" flavor. I didn't say I was going to lay such
>a theory out on a plate for you. But I do want to get you
>thinking and working along these lines so we can start
>getting closer to the goal of *truly* "strong crypto", to
>replace the wishful thinking that people are relying on today.
Well, I'd say that the academic cryptographic community has already been
thinking along these lines for many years. You're not the first to call
for such a theory, and what you're asking for would surely count as a
Holy Grail of cryptography.
What's lacking is not desire, but knowledge how to proceed. Many people
have worked on the problem, but the path to success is not clear, and
it seems to be quite a difficult problem. I'd of course welcome any
progress in this direction, but at the moment I don't see how to begin.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Safe to use DSS key for DH?
Date: 11 Mar 2001 00:00:57 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
DJohn37050 wrote:
>Bleichenbacher recently had an attack on DSA, this shows something good for one
>thing is not necessarily good for another.
How so?
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 11 Mar 2001 00:05:14 GMT
Eric Lee Green wrote:
> On Fri, 09 Mar 2001 14:39:04 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]
> m> wrote:
> >Compressed files: This was another point raised. Wouldn't you agree
> >that the user is intending to overwrite the file as it exists. How
> >it got to be the file it is is not the concern of the OverWrite
> >program. This may be a concern of the user.
>
> The point was that compression changes the file. You may think you're
> writing 1,000,000 bytes of data to the file. But the user's actual
> file may have been 865,000 bytes of data, and your actual file that
> you are trying to overwrite the first file with may be 665,000 bytes
> of data once the OS finishes compressing it. What happens to the
> remaining 250,000 bytes of data? Well, it's still lying around on the
> disk until it is overwritten by some other operation.
This vastly understates the problem. He has already stated that he writes a
constant to every byte. I believe the example was 222. Even a simple RLE will
compress that megabyte by a hundred or so, thus leaving 99% of the original image
unmodified.
Can you take this to some other group?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Digital enveloppes - Off Topic
Date: Sun, 11 Mar 2001 01:10:13 +0100
"John A. Malley" wrote:
[snip]
> Shaking my head in disbelief,
I guess that this US patent is simply the first act of
the drama of the next award of a Nobel prize in physics
to that great inventor Mr. Strom.
M. K. Shen
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: Schneier's cryptanalysis self-study course
Date: Sun, 11 Mar 2001 01:18:17 +0100
Ok, I hope that will be a productive cooperation.
KB
Kay Connelly wrote in message <[EMAIL PROTECTED]>...
>I'm starting to work through Bruce Schneier's "A Self-Study Course
>in Block-Cipher Cryptanalysis"
------------------------------
Reply-To: "Dan Beale" <[EMAIL PROTECTED]>
From: "Dan Beale" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: Why do people continue to reply to Szopa?
Date: Sun, 11 Mar 2001 01:28:07 -0000
"Paul Crowley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> William Hugh Murray <[EMAIL PROTECTED]> writes:
> > Dan Beale wrote:
> >
> > > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > <snip everything>
> > >
> > > Having cleared my kill-filter i am _amazed_ to find you still
trolling the
> > > crypto groups Anthony. Have you learnt any math yet?
> >
> > No, but not because we have not tried to teach him.
> >
> > Would you leave if you were getting the attention he gets?
>
> Can someone explain this to me? I've never written an article that
> addressed Szopa directly, and I never plan to; he's clearly a loon who
> will never learn anything. The only reason to post a followup to
> something he's written is to warn off newcomers who might otherwise
> believe some outlandish claim or other. Yet many highly intelligent
> and knowledgable people waste a great deal of effort trying to explain
> basic facts about computer security to a man who is clearly unable to
> grasp them. Why?
>
> If you think he's a troll then don't feed him. If you think (as I do)
> that he's sincerely clue-resistant, what's the point?
sorry,
you are right.
he is quite clearly bonkers. I was just surprised to see him _still_
here, still coming up with the same nonsense after he had spent _ages_ in
my 'blocked senders list'.
anyway, back to lurking...
------------------------------
Reply-To: "Dan Beale" <[EMAIL PROTECTED]>
From: "Dan Beale" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Sun, 11 Mar 2001 01:36:21 -0000
"Sundial Services" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Do not feed the trolls, Tom. They love to eat and make noise.
>
>
> Tom St Denis wrote:
> >
> > "Ryan M. McConahy" <[EMAIL PROTECTED]> wrote in message
> > news:3aa9594e$0$62146$[EMAIL PROTECTED]...
> > > I am _not_ a troll! If I can't find it from you, I'll find it
somewhere
> > > else.
> >
> > What? Applied Crypto is not free so why ask here?
> >
> > Tom
>
people may not agree with giving away the (possibly pirated) text, but how
about the source code, which (last time I checked) was not available to
non-Americans.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Sun, 11 Mar 2001 01:37:38 GMT
"Dan Beale" <[EMAIL PROTECTED]> wrote in message
news:ZCAq6.1295$Q7.26476@stones...
>
> "Sundial Services" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Do not feed the trolls, Tom. They love to eat and make noise.
> >
> >
> > Tom St Denis wrote:
> > >
> > > "Ryan M. McConahy" <[EMAIL PROTECTED]> wrote in message
> > > news:3aa9594e$0$62146$[EMAIL PROTECTED]...
> > > > I am _not_ a troll! If I can't find it from you, I'll find it
> somewhere
> > > > else.
> > >
> > > What? Applied Crypto is not free so why ask here?
> > >
> > > Tom
> >
>
> people may not agree with giving away the (possibly pirated) text, but how
> about the source code, which (last time I checked) was not available to
> non-Americans.
I dunno who wrote the code in the back of Applied crypto BUT IT SUCKS!.
It's the most sloppiest poorly written code I have ever seen. My blind dog
with only three legs (that we call "tripod") can write better code by
randomly typing keys on the keyboard.
Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography
Date: Sun, 11 Mar 2001 01:39:16 GMT
On Sat, 10 Mar 2001 10:52:08 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>It's most likely an illegally made available copy. If it were
>legitimate, it would be on the same website as HAC,
Why? Bruce Schneier is not one of the authors of HAC.
If it were legitimate, it would be on counterpane.com is what I'd be
more inclined to think.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Fred Galvin <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Sat, 10 Mar 2001 20:19:22 -0600
On Sat, 10 Mar 2001, John R Ramsden wrote:
> Mind you, there's no reason why the sender of a text message
> couldn't start by running a program to intersperse short sequences
> of random letters all through the message such that the overall
> frequencies of letters and letter groups would be made
> unpredictable,
Isn't that what compression coding does? Turn a normal message into
something that approximates a random sequence of bits?
> while at the same time the recipient could still interpret the
> decrypted message "semantically" and isolate the meaningful text
> from the extra noise.
>
> I guess the main disadvantage of this would be to increase the
> message length, and introduce the possibility of ambiguity or
> misinterpretation especially if the original text itself included
> "random" letters such as vehicle licence plates.
I guess compression codes are supposed to be invertible, and (as their
name suggests) decrease the message length. But I haven't had lesson
one in the subject either.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 18:57:41 -0800
"Trevor L. Jackson, III" wrote:
>
> Anthony Stephen Szopa wrote:
>
> > Benjamin Goldberg wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > > >
> > > > Troed wrote:
> > > > >
> > > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > >This is a personal use program for windows. I think it is fair to
> > > > > >say this program is for and intended for a non multitasking
> > > > > >environment.
> > > > >
> > > > > It's for Windows 3.x only? Windows 95 and up are pre-emptive
> > > > > multitasking - or what are you talking about?
> > > > >
> > > > > >Take a look at my floppy disk test results I just posted. They
> > > > > >seem to cramp everything pretty much all the detractors have been
> > > > > >saying.
> > > > >
> > > > > Floppy != Harddrive
> > > > >
> > > > > ___/
> > > > > _/ - Software Engineer working in the development of operating
> > > > > systems
> > > >
> > > > You should not have other programs running at the same time as you
> > > > are running the OverWrite program that will be making demands on the
> > > > system such that the overwrites to the hard drive will be delayed by
> > > > competition from these other programs for system resources. You
> > > > don't want to be running multiple tasks or programs while the
> > > > OverWrite program is running if at all possible.
> > >
> > > If your algorithm is designed properly, that should not make a
> > > difference.
> > >
> > > --
> > > The difference between theory and practice is that in theory, theory and
> > > practice are identical, but in practice, they are not.
> >
> > Catch 22!!!
> >
> > You've been all telling me that there is no way to design the
> > program properly to make sure 100% of the time that the physical
> > overwrites are taking place because of optimizations built in to the
> > Windows OS.
>
> Hardly.
>
> There is no platform-independent mechanism able to make the desired
> guarantee. Some platforms have specific features that allow for the support
> of the guarantee.
>
> >
> > Now you are telling me that it can be done. Are you taking both
> > sides?
>
> Yes. They are two separate coins.
>
> >
> >
> > I have attempted to make the overwrites take place by allowing
> > enough time between subsequent calls to the write and fclose
> > functions in each pass so that the OS will make these overwrites.
> >
> > The overwrites should physically take place as long as there are not
> > other competing physical writes such that any subsequent write and
> > fclose instructions are processed before the prior overwrite has
> > had a chance to physically take place.
> >
> > I believe this was the issue.
>
> No.
>
> The issue was the non-trivial nature of the problem. Your approach was
> simplistic and thus not able to provide the assurance you claimed it could.
> This appears to be a consistent property of the software you write. Perhaps
> you would be happier with a different hobby?
My my. You sound like a frustrated NSA employee.
Tell us when you have the remotest ideas on how to successfully
attack the theory upon which OAP-L3 is based.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 18:59:13 -0800
Benjamin Goldberg wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Benjamin Goldberg wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > > >
> > > > Troed wrote:
> > > > >
> > > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > >This is a personal use program for windows. I think it is fair
> > > > > >to say this program is for and intended for a non multitasking
> > > > > >environment.
> > > > >
> > > > > It's for Windows 3.x only? Windows 95 and up are pre-emptive
> > > > > multitasking - or what are you talking about?
> > > > >
> > > > > >Take a look at my floppy disk test results I just posted. They
> > > > > >seem to cramp everything pretty much all the detractors have
> > > > > >been saying.
> > > > >
> > > > > Floppy != Harddrive
> > > > >
> > > > > ___/
> > > > > _/ - Software Engineer working in the development of
> > > > > operating systems
> > > >
> > > > You should not have other programs running at the same time as you
> > > > are running the OverWrite program that will be making demands on
> > > > the system such that the overwrites to the hard drive will be
> > > > delayed by competition from these other programs for system
> > > > resources. You don't want to be running multiple tasks or
> > > > programs while the OverWrite program is running if at all
> > > > possible.
> > >
> > > If your algorithm is designed properly, that should not make a
> > > difference.
> >
> > Catch 22!!!
> >
> > You've been all telling me that there is no way to design the
> > program properly to make sure 100% of the time that the physical
> > overwrites are taking place because of optimizations built in to the
> > Windows OS.
>
> Well, no way to do it with platform independent stuff like the stdio
> library.
>
> > Now you are telling me that it can be done. Are you taking both
> > sides?
>
> Heh. Yes and no. If you algorithm is designed properly, it will work
> regardless of whether other things are running, but if your algorithm
> uses platform independent code, there is no way at all for it to
> provably, consistently, work.
>
> I suppose that to you, with your limited knowledge and abilities, this
> might appear to be a catch 22. The trick to designing the algorithm
> properly is that you have to write code which is targeted for your
> specific platform: probably this will have OS specific calls, and it
> might possibly even need to be added to the kernel, to the OS itself, to
> work.
>
> > I have attempted to make the overwrites take place by allowing
> > enough time between subsequent calls to the write and fclose
> > functions in each pass so that the OS will make these overwrites.
>
> A good idea, but how much is "enough time?" Also, is your clock
> measuring what the computer refers to as "user time," or "system time?"
> Or are you trying to do something which measures wall clock ("real")
> time?
>
> If you can learn from Microsoft exactly how long it takes for the OS
> timer to automatically write the OS write-behind buffers to disk, and
> what it is on ALL the various dos/win platforms you are willing to
> support your software for, and have the program figure out which
> platform it's running on, then you can realistically say that it will
> assuredly work, without fear of contradiction.
>
> However, if you just say "enough time" without learning what it is for
> real, or without siting the source for this info, then you're going to
> get people disagreeing with you, or at least saying, "How do you know
> that for sure?" and/or "Prove it!"
>
> Note that I, personally, do not believe that using the OS timer for
> buffer flushing is the best way of doing things. The best way, IMHO, is
> to find a windows-specific library function which directly interacts
> with windows's write-behind functionality. (1) Your software should
> read from the OS whether write-behind is turned on, then your program
> should turn it off, and, after doing the writes, your program should
> restore write-behind to it's original setting. (2) Your software
> should, after each fclose, send commands to the hdd which causes the hdd
> to physically write its buffers. There are OS->hdd commands to do this,
> as they are sent from the OS to the hdd during shutdown.
>
> A third, best, possibly only trustable way, is the following:
> 1) locks the file so that no other program can have it open
> 2) access OS internals to learn what file system is in use
> 3) access OS internals to learn what hdd sectors the file resides on
> 4) access device driver internals or OS internals to push blocks of data
> (random whitening, or whatever it is your replacing the data with)
> directly to the hard drive, bypassing the OS io operations.
> 5) access device driver internals or OS internals to command the hdd to
> physically write the blocks of data it has in memory to the disk.
> 6) repeat 4 and 5 as necessary.
>
> Great care should be taken when writing disk sectors directly to not
> mess up file system info (like pointers to next/prior blocks, whatever).
>
> > The overwrites should physically take place as long as there are not
> > other competing physical writes such that any subsequent write and
> > fclose instructions are processed before the prior overwrite has
> > had a chance to physically take place.
>
> It's not that physically writing takes a while. It's that once you
> finish sending data to the OS, it sits around in the OS buffers...
> The only things which cause the OS buffers to get sent to disk, is
> enough writes so that the buffer cache gets full, or a special clock
> going off, indicating, "this has sat around for a while without being
> accessed, there's probably no performance gain to keeping it around in
> memory, it would be a good idea to write it to disk"
>
> Remember, fclose only flushes C library buffers (stdio buffers), and
> doesn't do anything about OS buffers.
>
> Also, you have to find sources of information on hard drive buffers. I
> have no clue as to how long the hdd keep stuff around -- I've heard OS's
> keep buffers around for as long as 30 seconds, but I've never read any
> info on how long various hdds keep data in their buffers. Is it flushed
> by timer, or only when the hdd buffers are full? I don't know. You
> have to find this out for people to be able to trust your software. Or
> else you have to find a way to send commands directly to the hdd,
> telling it to flush its own buffers.
>
> > I believe this was the issue.
> >
> > This is why I recommend that other programs not be running.
>
> Hmm. Unless those other programs are accessing the data you're
> overwriting, then it still shouldn't make much of a difference. At
> least, not with the simplistic approach you're taking.
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
Check out my new thread: OverWrite: best wipe software?
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: 10 Mar 2001 18:56:53 -0800
"Henrick Hellstr�m" <[EMAIL PROTECTED]> writes:
> That's not entirely true. Any message authentication scheme have to have the
> application reject faulty data, namely the messages that fail the
> authentication tests.
>
> Furthermore, many kinds of client/server system (pop, smtp, http, dns,
> telnet, the ftp command channel, etc) have to check for faulty data anyway,
> because they are expecting a strictly formatted input.
But code in application layers is often written without the assumption
that the format check has security implications. Imagine an FTP daemon
that rejects an unknown command by including the offending command name
in the response; "FOO" results in "FOO: unknown command". Under these
circumstances, it seems possible that an attacker could exploit this
behavior under your model to get chosen ciphertext pairs and use it
to leverage attacks that would not be possible with explicit MACs.
A user-friendly feature at the application level suddenly turns into
a security weakness when these abstraction barriers aren't respected.
> --
> Henrick Hellstr�m [EMAIL PROTECTED]
> StreamSec HB http://www.streamsec.com
>
>
> "David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
> news:98baf3$dap$[EMAIL PROTECTED]...
> > Henrick Hellstr�m wrote:
> > >Every application that utilizes any kind of security primitive has to be
> > >designed in a particular way in order not to weaken that security
> primitive.
> >
> > I prefer to minimize the number of ways that a cipher can be misused.
> >
> > Since there are alternatives (e.g., MACs) that do not require the
> > application to reject gibberish, I see no good reason to introduce
> > unnecessary failure modes.
>
>
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 11 Mar 2001 03:04:40 GMT
Subject: Re: Safe to use DSS key for DH?
The PRNG for DSA would work fine for DH but not for DSA, due to the new attack.
NIST has always said that just cuz something was endorsed in one context it
should not be assumed to be endorsed in another. It is just that things are
reversed in this case, but the principle still applies.
Don Johnson
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
