Cryptography-Digest Digest #36, Volume #9 Fri, 5 Feb 99 01:13:03 EST
Contents:
Re: Cipher used by iomega in ZIP products ? (Michael Curry)
Re: Loony question (wtshaw)
Threat Models: When You Can't Use a One-Time Pad (John Savard)
Re: Cipher used by iomega in ZIP products ? ("Trevor Jackson, III")
Re: What's the newest on MD4? (Gregory G Rose)
Re: I hate to bring up PRNGs again...
Practically unbreakable encryption for windows files/folders ("olympic")
Re: What is left to invent? (Toby Kelsey)
Re: Threat Models: When You Can't Use a One-Time Pad
Re: Foiling 56-bit export limitations: example with 70-bit DES
([EMAIL PROTECTED])
Re: David _R._ Scott
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Curry)
Subject: Re: Cipher used by iomega in ZIP products ?
Date: Fri, 05 Feb 1999 00:22:19 GMT
On Thu, 04 Feb 1999 15:43:37 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Paul Gover wrote:
>
>> I thought it was ROT-13, with two rounds for extra security :-)
>
>Hmmmm, triple-ROT13. What a concept! Thinks that's enough?
Given the fact that it's possible to bypass the Zip disk encryption
via simple physical means (all you need is another disk with a
password you know and a paper clip) the actual method used becomes
rather a moot point.
Or have those wise men at Iomega finally dealt with that problem?
Mike
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Loony question
Date: Thu, 04 Feb 1999 13:34:55 -0600
In article <[EMAIL PROTECTED]>, Brett W <[EMAIL PROTECTED]>
wrote:
> fungus wrote:
> >
> > Phillip George Geiger wrote:
> > >
> > > Would a particularly awful track off a CD with a lot of
> > > screeching guitars and howling monkeys be a decent source
> > > of random numbers?
> > >
> >
> > (this should be in the FAQ)
> >
In a left handed way, it might be thei already; if the music is really
bad, then the copies of it will be less likely to be generally
distributed....security by obscurity.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Threat Models: When You Can't Use a One-Time Pad
Date: Thu, 04 Feb 1999 21:28:47 GMT
This relates to a discussion that went on in another thread a while
back:
Suppose I'm sending an E-mail to a friend, and I don't want a hacker
reading it.
Then, it is quite true that, for the cost of a CD-R or a floppy, and a
stamp, if I have a way of generating true random numbers available to
me, the one-time-pad is a satisfactory way of obtaining security for
that communication.
It's theoretically perfect, and it's simple. Why bother with anything
else, some people would ask.
I don't ask that question myself: I think conventional symmetric
ciphers, with keys of reasonable length, can be as secure as anyone
might need, and they are even more convenient. But I have to admit
that this is a valid approach to this situation as well.
Suppose I want to encrypt a file on my hard disk, and I don't want
somebody who later obtains physical access to my computer to read it.
_Now_, can I use the one-time pad?
Obviously, if my one-time-pad were stored in an unencrypted form on
the hard disk of the same computer holding the encrypted file, I
wouldn't have any security at all.
In the E-mail case, I wasn't concerned about such a threat: I assumed
that, as far as the people who might want to read my mail were
concerned, my computer was inaccessible. So I didn't worry about
having to lock up my disk of key bits.
In this new situation, though, the one-time pad, however it is used,
appears to be _irrelevant_.
If I encrypt the one-time pad with a symmetric cipher: my security is
the same as if I encrypted my file with that symmetric cipher.
If I keep the one-time pad on a floppy in a safe: my security is the
same as if I kept my file, unencrypted, on a floppy in that safe. And
the convenience of my access to that file is exactly the same too.
Can I have a secure system of disk encryption that involves a one-time
pad? Yes: but it will owe none of its security to the one-time pad.
The one-time pad encryption step will simply function as an extra step
that contributes nothing.
That is a natural consequence of the fact that the key for a file is
exactly as big as the file itself in this system. Conventional
symmetric encryption lets you protect a big file with a small key -
one that is easy to handle, and thus can be stored in a secure place
where it would be impractical to place the file instead (hence
avoiding the need to encrypt at all).
Such as memorizing a key phrase.
The principle is:
1) Obtaining security from cryptography requires a place where key
material can be stored securely.
2) Cryptography is necessary if the data being encrypted is stored, or
transmitted, in a fashion that is not considered secure.
Only when data is transmitted from point A to point B do you have a
case where being able to store the whole message securely at A and at
B doesn't mean you have no problem, and thus that is when the
one-time-pad is useful.
Of course, it still requires the ability to distribute the key
securely as well: but the size of a one-time pad is not the major
obstacle to that. Instead, one may be able to transmit a long message
securely at an early time (prior to hostilities, for example) or by a
slow channel (a courier) but not later or more quickly (over radio or
the Internet), and so the usability of the one-time pad is obvious. So
obvious that one sometimes forgets to point out _why_ it is usable.
Public-key methods still require a copy of the secret key to decrypt
something encrypted with them. But they don't require any transmission
of key material from point A to point B, so they are useful when
circumstances prevent the use of one-time pad or symmetric methods for
communications.
In a way, PKC is the opposite of OTP, with symmetric in the middle:
PKC - no key, symmetric - tiny key, OTP - large key.
However, that view doesn't explain why OTP is useful only for
communications, and PKC is also more useful for communications. PKC
uses no communication of a _secret_ key, but it does use a secret key,
and usually that key is larger than that used by a symmetric cipher.
Also, that key is usually generated by an a priori method, and thus
can't be produced from a pass phrase.
Thus, the secret key of PKC is less awkward than an OTP key, but more
awkward than that of a symmetric method. The public key, since it
doesn't need to be kept secret, is not troublesome for communications
- it's as if there is no key at all for that purpose.
I hope this little essay will clear up confusion about why different
classes of ciphers are usable for different purposes. (Of course, I
didn't get into the difference between stream and block ciphers...)
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
Date: Thu, 04 Feb 1999 21:02:47 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Cipher used by iomega in ZIP products ?
Michael Curry wrote:
> On Thu, 04 Feb 1999 15:43:37 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >Paul Gover wrote:
> >
> >> I thought it was ROT-13, with two rounds for extra security :-)
> >
> >Hmmmm, triple-ROT13. What a concept! Thinks that's enough?
>
> Given the fact that it's possible to bypass the Zip disk encryption
> via simple physical means (all you need is another disk with a
> password you know and a paper clip) the actual method used becomes
> rather a moot point.
>
> Or have those wise men at Iomega finally dealt with that problem?
Since Rot-13 is its own inverse, any even multiple leaves the ciphertext
== the plain text. Any odd multiple is identical to a single operation.
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: What's the newest on MD4?
Date: 4 Feb 1999 19:38:25 -0800
In article <[EMAIL PROTECTED]>,
Tom McCune <[EMAIL PROTECTED]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In article <797jc9$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Gregory G
>Rose) wrote:
>
>>Hans Dobbertin's paper demolishing MD4 was
>>published a month or two ago in the Journal of
>>Cryptology, although the result has been known for
>>a couple of years. While MD5 has not been
>>"demolished", it is certainly suspect.
>
>Any chance this is online, or perhaps even an Abstract?
Abstract:
http://link.springer.de/link/service/journals/00145/htabst/11n4p253.html
You can get the paper online, but you have to be a
subscriber... which I'm not.
Dobbertin's earlier paper about MD4 and his
two-pager which shows a pseudo-collision for MD5
are online under Bennet Yee's home page (don't ask
me why...) at:
http://www-cse.ucsd.edu/~bsy/sec.html
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: I hate to bring up PRNGs again...
Date: 5 Feb 99 03:50:09 GMT
Brett W ([EMAIL PROTECTED]) wrote:
: Although you may have a whole tonne of things that are psuedo-random and
: not that high on entropy, could you combine several of these independant
: devices together to make stronger PRNGs?
Oh, very definitely you can, since all strong ciphers are built out of
small steps that are not strong in themselves.
Because, though, one can also combine weak PRNGs together badly, in a way
that doesn't cause improvement, this tends to be disparaged rather than
recommended, unless one knows what one is doing.
As for the neglect of this sort of cipher by competent investigators, that
has to do with block ciphers having more theoretical interest (and
public-key systems having more theoretical interest yet), and the fact
that block ciphers can be easily used to construct stream ciphers in
practice, so they are considered more useful.
(In theory, one could with difficulty define any stream cipher as a block
cipher and vice versa: but in practice, a block cipher of reasonable size
can be used to produce a particular kind of related stream cipher without
loss of security.)
John Savard
------------------------------
From: "olympic" <[EMAIL PROTECTED]>
Subject: Practically unbreakable encryption for windows files/folders
Date: Fri, 5 Feb 1999 00:07:30 +0700
Practically unbreakable encryption for windows files/folders can be
downloaded from
http://www.fis.lv/olympic
------------------------------
From: Toby Kelsey <[EMAIL PROTECTED]>
Subject: Re: What is left to invent?
Date: Thu, 4 Feb 1999 06:32:18 +0000
>>This presumes that decipherments always fall randomly in the space of
>>all possible (intelligible or not) messages. It is this unjustified
>>assumption I am questioning (not for DES, but encryption in general).
In article <[EMAIL PROTECTED]>, John Savard <jsavard@te
nMAPSONeerf.edmonton.ab.ca> writes
>If you're referring, instead, to some sort of _accidental_ bias
>towards intelligible plaintext, not concerning oneself with that is an
>acceptable simplification in practice, to be avoided when - and if - a
>cipher system is encountered where such a bias exists, and there is a
>way to say something useful about it.
I was considering a designed-in bias. It seems to me that if such a
system was practicable the extra security would be worth the effort.
The problem is designing a text compression method which understands
enough of the structure, grammar and vocabulary of intelligible text to
give close to optimal compression. It would therefore probably have to
be language-specific, if not domain-specific. Even if it has an
extensive vocabulary list it is distinct from a code since the
compression method (part of the algorithm, not the key) could be
publicly known.
I would be interested to know if this approach has been tried.
Toby
--
Toby Kelsey
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Threat Models: When You Can't Use a One-Time Pad
Date: 5 Feb 99 03:42:57 GMT
Trevor Jackson, III ([EMAIL PROTECTED]) wrote:
: The second issue is that the use of lesser security to protect the pad may
: be a bit stronger than that same security used to protect the plaintext.
: I am unable to formulate this with the rigor I desire, but, FWIW, I'll
: sketch the fundamental concept. The use of an OTP as an intermediate
: cipher enlarges the unicity distance of the system past the length of the
: message.
In practice, you probably would be right. A very slight bit of additional
security is provided, since an attacker would have to match the correct
one-time-pad sheet to the correct encrypted file.
But assuming no additional means of _encryption_ is employed, I assume
that the encrypted file is stored with an unencrypted pad number.
Now, if we encrypt the one-time-pad with a symmetric algorithm, and do the
same thing to the enciphered message, when solving both ciphers, we're
working back to pure random text, and so we have to look at correlations
between two plaintexts which have no redundancy individually. Is this
harder than cracking the two ciphers, applied one after the other, to the
plaintext?
I'd tend to think it might be, but when I mentioned this, I've heard a
contrary opinion voiced.
If one of the two files - the pad or the ciphertext - is encrypted by an
additional method, then the improvement in security, if any, is much
smaller, in my opinion.
But by 'more secure', in *either* case, I mean the work factor is
(possibly) greater. The _unicity_ distance is not affected, since a
brute-force search for plaintext will require trying exactly the same
number of keys, and verifying plaintext will only take a trivial step.
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Fri, 05 Feb 1999 04:59:10 GMT
In article <79cvgs$5qn$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <79a19p$n3t$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> [snip]
> > The reasons why adding a previous encryption to the plaintext are, mainly:
> >
> > 1. you are wasting controlled-bits if the previous encryption uses
> > secret-bits. Mind you, this is important not only for those that live under
> > such constraints but also to decrease secret-key sizes (smart-cards, etc).
>
> I don't follow you. In your scheme, you have generated M bits and used them
> to select an "unkown key." It doesn't cost much to apply the same unknown
> key to both the plaintext and the DES ciphertext. See DESX.
>
Peter:
First, please correct my mangled openning phrase above, from:
> > The reasons why adding a previous encryption to the plaintext are, mainly:
to:
|The reasons why adding a previous encryption to the plaintext is less
|effective than adding post encryption to the ciphertext are, mainly:
Sorry for the butcherous copy and paste...
Next, I will try to handle several of your questions at once -- also, more
quantitatively. The comments below will be added to the current paper, as I
believe your question above may be quite common and has two sides that need to
be discussed in separate: cost of a brute-force attack and unicity gain.
My claim (as above, for DES 56-bit) was that M-bits of added uncertainty
increase security against brute-force attacks MORE when added to the
ciphertext than to the plaintext. The reason is quite intuitive, as any
change done on the ciphertext side is multiplied by 2^56 possibilities (for
56-bit DES) at the plaintext side.
This can be shown using data from http://www.mcg.org.br/unicity.htm and
http://www.mcg.org.br/nrdes.htm -- as I give below for each case:
1. the first case leads to an expected *average* workload of
(1/2)*(2^M)*(2^56) = 2^(55+M)
tentative decryptions before the brute-force search ends with a "correct
message" and hence a correct key, which detection depends on (3 ~ 300)*(2^M)/2
tentative plaintexts to be analyzed per DES key.
NOTE: This means an effective (56 + M)-bit key, which for M=14 (14 is an
example, no more than that) is 56 + 14 = 70 and thus gives the name to this
thread -- 70-bit DES, export-free according to US sponsored Wassenaar
Arrangement since it only depends on 56 bits initially secret to an attacker
but known to the recipient. Please note that as the message is received, the
recipient is entitled to increase the number of secret bits without limit --
viz, the contents of the encrypted message itself! Thus, WA does NOT prohibit
the recipient to "gain" M secret-bits as transported by the 56-bits protocol
-- they just MUST NOT be required BEFORE the protocol begins. In fact, when
the M-DES protocol begins, the M-bits are unknown to all observers, recipient
and attacker alike.
2. the second case leads to to an expected *average* workload of
(1/2)*(2^56) = 2^55
tentative decryptions before the brute-force search ends with a "correct
message" and hence a correct key, which detection depends on (3 ~ 300)*(2^M)/2
tentative plaintexts to be analyzed per DES key.
Which total workload for a brute-force attack is larger? If detection cost
scales with the number of possible messages to be handled and is worth D per
message, and if DES decryption costs C per event, then the cost ratio (1)/(2)
is:
ratio = [C*2^(55+M) + D*(3 ~ 300)*(2^M)/2]/[C*2^55 + D*(3 ~ 300)*(2^M)/2]
then for M =14 (for example) it is clear that the ratio >> 1. Therefore, it
is more effective to add uncertainty to the ciphertext than to the plaintext
-- as one may also see from the intuitive argument given above.
Thus, to make brute-force attacks more expensive, any M-bit that I have would
go preferentially to the ciphertext up to the *maximum* that I can stuff in
there -- which is 64-bits for DES. AFTER that limit, yes, I would start to
use the remaining M-bits to harden the plaintext, not before though.
However, notice that unicity MAY exhibit an opposite behavior -- in
comparison to brute-force workload. As a function of how the M-bits are
reflected in H(M) and H(K), the unicity COULD benefit more from plaintext
"hardening" than from added encrytpion to the ciphertext. This can be readily
derived from the unicity formula itself:
unicity = n = H(K)/(|M| - H(M))
This formula shows that the key-entropy H(K) can be seen as a "gain factor"
over 1/(|M| - H(M)). Now, I have to ask two questions:
1. What is the object of pre-encrypting (or, pre-encoding) the plaintext? To
increase H(M). If using one M-bit adds one uncertainty bit to H(M),
differentiation shows that unicity increases by (n^2)/H(K).
2. What is the object of post-encrypting the ciphertext? To increase H(K). If
using one M-bit adds one uncertainty bit to H(K), differentiation shows that
unicity increases by n/H(K).
Thus, what is largest -- case (1) or in case (2)? The ratio (1)/(2) is n,
which is larger than one, usually. Which shows that one added uncertainty bit
in the plaintext entropy increases unicity more than one added key --
however, they may need different amounts of M-bits for the same effect.
Hence, the "MAY" above.
BTW, just recently, Tony Bartoletti ([EMAIL PROTECTED]) obtained some preliminary
but IMO interesting results on plaintext hardening without any secret-key --
which can be used to complement the technique described for M-DES, on the
plaintext side. Please see the mcg-talk archives
[http://www.mcg.org.br/emails.htm].
> > 2. if the encryption uses a second unknown-key then you are increasing the
> > recipient's burden to obtain that unknown-key in the same amount as the
> > attacker's, irrespective of DES,
>
> I did not suggest that you use a 2nd unknown key.
I was just closing that door ;-)
>
> > 3. you are working only in plaintext recognition, where the most effective
> > attackers (NSA, for example) excel.
>
> The purpose of pre-encrypting, in addition to post-encrypting, is to make the
> post encryption more secure, in the event that the same message is sent twice
> with the same DES key. I thought I made that clear.
>
First, let me discuss your assumption. You suppose that repeating the DES key
for the same message would make the post-encryption in M-DES less secure. I
affirm that this is not the case, not even for the same repeated M-bit
unknown-key. Can you please tell me how you derived your assumption? Maybe I
can more easily spot the difficulty if you tell me the steps you took -- of
course, using the protocol given in http://www.mcg.org.br/unicity.htm
Second, this should not be confused with the related question of collision
after the final M-DES XOR encipherment, that can occur in two different ways
as discussed in http://www.mcg.org.br/unicity.htm -- which, however, only
affects the attacker's knowledge whether a message was repeated, not what the
message was or is.
> > That is mainly why I said that if the plaintext is encrypted with an
> > unknown-key (the choice I am considering) then the intended recipient will
> > gain less in comparison to the attacker. I hope it si clearer.
>
> It's not, really.
It was not ;-) Hope to have improved.
>
> > > [snip]
> > > > 1. That is not what WA says -- it is the amount of secret-key that is
> > > > controlled. And, M-DES only defines a secret-key that is 56-bit wide
> Please
> > > > read the WA.
> > >
> > > I think I was clear that I was describing US export law.
> >
> > Still, ditto as I wrote. The M-DES method complies to the published US
> > regulations -- and shows how impossible it is to try to control
> > cipher-strength just by controlling bit-lengths. It further shows that you
> > can't really ban secure ciphers because you cannot control what the other
> > side ignores but may find much sooner than the attacker -- the unknown-key.
>
> You are mistaken about U.S. export law. You've never worked to get export
> approval for any real product, have you?
This is not the issue here -- and, as everyone that has tried (did you?)
knows, each case is different. Indeed, the US export law seems to be quite
different for Netscape with 40-bit encryption for export and PGP that exports
strong encryption -- both, US companies and US-made software.
However, you must not ignore that the US-sponsored change in the Wassenaar
Arrangement was exactly targeted to harmonize different criteria, inland and
abroad. Some have applauded the intiative as "loosening up the US export
restrictions" ... others have decried the initiative as "depriving the world
of its privacy". However, as I commented in the thread "On leaving the 56-bit
export limitation" -- both sides are mislead. The number of bits in a
secret-key is NOT a good metric for the security of the corresponding cipher.
Which was the motivation for this thread -- to show that, yes, keep only
56-bits secret ... we can still bootstrap that to 70-bit or even more to
120-bit ... or even more as I will post here in the next days.
It is even possible to achieve *perfect secrecy* for unlimited length English
text messages when Bob and Alice start only with a 56-bit DES secret-key and
work up a proper M-DES protocol.
And, this cannot be stopped by any regulation because it does not really
depend on the cipher (eg, DES) or the export-free software that implements
it, but how it is used -- which is as diverse as there are users and
applications. Since, here, the brute-force strength derives not from the
secret-key strength (but, from "open ignorance"), there is nothing that the
export-free software would need to do differently -- since the export-free
software deals only with the secret-key part, which can be 56-bit without
compromising security.
This is the point here -- secret-key bit-length is not the deciding factor to
grade the security of cipher systems. And, what is -- cannot be controlled by
controlling cryptography.
> > >If you really want
> > > your 56-bit algorithm to be strong,
> >
> > It is really negatively surprising to see you mention "If you really want
> > your 56-bit algorithm to be strong, " when the algorith is 70-bit strong and
> > NOTHING that you or anyone else have said so far has decreased the
proposal's
> > security! So, your phrase is empty. What is your objective, to pass through
> > with a previoulsy denied qualification? BZZT!
>
> Hey, don't get hostile. My intention was to provide useful feedback. If you
> weren't interested in such, why post to sci.crypt?
>
"BZZT!" was not meant to be hostile ;-) However, it was IMO a just complaint
in a good-natured graphical way -- an alarm. Apparently, you had lost your
line of argument in the same e-mail. First, you said that M-DES was "too
strong" for US-export laws ... then you said it had 56-bits...and I called
out the contradiction plus an empty statement.
> > For a productive discussion, please first acknowledge what has been
> > established -- not invent what has even been denied. The presented M-DES
> > cipher is secure for 70-bits and so I have proven publicly -- you cannot
> > name one weakeness (of course, if you follow what is in the paper). And,
> > the paper discusses how it can be secure to 120-bits or even more. These
> > are the points in discussion.
>
> I can name a weakness. The post-encryption is much easier to break if
> the same message is sent twice with the same DES key.
Why? Please prove that sending the same message twice with the same DES key
makes **the post-encryption** easier to break -- where I accept that you
focus only on the M-DES post-encryption mechanism with the XOR choice (even
though XOR is just one example, from all possible choices such as RC4, RC5,
RPK, Twofish, etc).
Please, consider also the two possible cases: equal unknown-key and different
unknown-keys in each transmission -- if you think that changes anything.
Please, read also what the paper says about it.
> > And, mind you, with one 56-bit DES encryption per block. Not three.
>
> It's true that the scheme I proposed takes Alice on the order of 4 times as
> long to decrypt as the scheme you proposed. It's also true that my proposal
> makes a cracker take 4*B times as long to break as your proposal, where B is
> the total number of blocks in the ciphertext message.
While it is also true that you are comparing apples with speedboats, no? The
issue here to exemplify a 70-bit DES protocol that only depends on a single
56-bit secret-key and a single DES encryption. Not the best possible protocol
-- not even what other choices one may have for M-DES. As I said, M-DES can
be anywhere from 56-bit ...to 120-bit or.. to 184-bit or ... even more, to
perfect secrecy. BTW, these modes will be exemplified next.
Thanks for the questions! Sorry for the l o n g answer but I though that
less would not touch all the points.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: David _R._ Scott
Date: 5 Feb 99 03:44:33 GMT
[EMAIL PROTECTED] wrote:
: I guess I can understand since you have not improved your
: ability to focus any clearer than when you use to comment
: in "The Gateway" or do I have you confused with a higher
: quality person?
No, it was I that attended the University of Alberta and wrote a number of
letters to its student newspaper.
John Savard
------------------------------
** 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
******************************
