Cryptography-Digest Digest #614, Volume #12 Tue, 5 Sep 00 06:13:00 EDT
Contents:
Re: Blum Blum Shub question (Benjamin Goldberg)
Re: RSA Patent. (Roger Schlafly)
Re: Capability of memorizing passwords (Benjamin Goldberg)
Re: Capability of memorizing passwords (Benjamin Goldberg)
Re: RSA Patent. (John Savard)
Re: QKD and The Space Shuttle (John Savard)
Re: Capability of memorizing passwords (John Savard)
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed (Eric
Smith)
Re: Capability of memorizing passwords ([EMAIL PROTECTED])
Linux password generation script (Paul Rubin)
Re: RSA Patent. (Roger Schlafly)
Re: A good MAC algorithm? (D. J. Bernstein)
Re: RSA Patent. (Arturo)
ISO9796 signatur format implementation ("Tor Rustad")
Re: DES weak keys in 3DES (Ragni Ryvold Arnesen)
Re: Capability of memorizing passwords (Mok-Kong Shen)
Re: Capability of memorizing passwords (Mok-Kong Shen)
Re: Blum Blum Shub question (Mok-Kong Shen)
Re: Serpent S-boxes (again) (Mok-Kong Shen)
Re: e-cash protocol concept, comments wanted (Ragni Ryvold Arnesen)
Re: DES weak keys in 3DES (Mark Wooding)
Re: Blum Blum Shub question (Mark Wooding)
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed (Mark
Wooding)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Blum Blum Shub question
Date: Tue, 05 Sep 2000 04:22:14 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
> >
> > I was recently looking over how the BBS public key system works, And
> > I think I might have an idea for a different way to use it.
> >
> > Set up your public and private keys, using all the special
> > considerations for choosing your two primes.
> >
> > The person encrypting, chooses some X and some Y, uses X as the key
> > to some secure block cipher, and sends Z=(X^2^Y mod n) (where n is
> > the public BBS key), and Y. The steps of BBS decryption should be
> > able to get X from Y and Z, and so we can get the key to decrypt. Y
> > can be a fairly small number maybe even a constant (which would mean
> > that it wouldn't need to be sent), and it would take far fewer steps
> > to get Z from X than would be needed for using the BBS stream cipher
> > to encrypt the entire message directly.
>
> Sorry, I am confused. You said that Z and Y are sent and
> n is public and that we can get the key (X) to decrypt.
> But who are 'we'? Does that designation exclude the
> opponent? Why?
I should have phrased that as being "and so the decryptor can get the
key to decipher."
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: RSA Patent.
Date: Mon, 04 Sep 2000 22:06:28 -0700
DJohn37050 wrote:
> You are wrong about RSA not being trademarked, I think. See RSA Security web
> page for more info.
>From this page, it appears RSA is now claiming some sort of
trademark on RSA:
http://www.rsasecurity.com/brandweb/stratpartners/trademark.html
However, you were there when RSA representatives stood up before
the IEEE P1363 committee and disclaimed any trademark on "RSA",
and said that anyone was free to use "RSA" to describe the
Rivest-Shamir-Adleman algorithm.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Capability of memorizing passwords
Date: Tue, 05 Sep 2000 05:16:34 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
> >
>
> > Of course, I personally think that if we're allowing arbitrary
> > length passphrases, and want 128 bits of entropy in that passphrase,
> > it would be much better to display a running count of the entropy of
> > the passphrase textfield, and require that it have at least 128 bits
> > of entropy.
>
> A practical problem is how to compute the entropy from a
> given passphrase, I suppose. Does anyone know of a method
> of doing that? Thanks.
Since we only need a rough estimate of the number of bits of information
content in the passphrase, we can use the standard definition:
Given the non-zero probability (p_i) of each value (i), the entropy (H)
for random variable (X) is
H(X) = -SUM( p_i log2 p_i )
Admittedly, this ignores the fact that english text is ordered, so there
is much less randomness than that, but we can compensate by requiring
that the H value of a passphrase be (for example) double the number of
bits that we plan on hashing down to.
Alternatively, one could compress the string, probably using something
optimized for english text, and call the bitlength of the compressed
version the entropy.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Capability of memorizing passwords
Date: Tue, 05 Sep 2000 05:57:45 GMT
jkauffman wrote:
[snip]
> hmmmm, sounds slightly dubious, how much entropy is there in
> "To be or not to be, that is the question". As soon as one
> allows users to have a say in passphrases they're going to
> choose stupid ones.
While it's entirely possible that people will still choose stupid
passphrases, it's rather less likely that their "stupid" choice will be
in an attacker's dictionary, simply because of the fact that it must be
long. This possiblity existed when 8 letter passwords were considered,
and can't really easily be eliminated. The closest we can come is to
try a dictionary attack on new user's passphrases, and reject them as
invalid if they're found.
Another thing to consider is that since English is considered to have
only about 1.2 bit of "real" entropy per letter (because it's well
ordered and easy to predict the next character from context), and my
experimental samples of text have about 3.5 measureable bits of entropy
per character, we can require that (3.5/1.2)*N bits of measureable
entropy be an a passphrase that's going to be hashed down to an N bit
key. Your example passphrase has a measureable entropy value of 139,
which is rather smaller than the 373 bits of measurable entropy we would
want for a key with 128 bits of real entropy.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: talk.politics.crypto
Subject: Re: RSA Patent.
Date: Tue, 05 Sep 2000 06:18:14 GMT
On Mon, 04 Sep 2000 09:54:23 -0700, Roger Schlafly
<[EMAIL PROTECTED]> wrote, in part:
>nym_test wrote:
>> You can't create RSA software, unless you are RSA employee.
>There is no trademark on "RSA". Others can (and do) create RSA
>software.
Although I do believe that RSA Data Security Inc. is claiming RSA as a
trademark, (see the "Biprime Cryptography" thread) the statement is
still confusing without an explanation, because RSA has been widely
used as the name of a specific algorithm - and the patent on that
algorithm is about to expire, later this month. Thus, people who are
not employed by RSADSI will indeed, even in the United States, be able
to create software implementing that algorithm.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.space.shuttle,talk.politics.crypto
Subject: Re: QKD and The Space Shuttle
Date: Tue, 05 Sep 2000 06:14:30 GMT
On Mon, 4 Sep 2000 12:42:21 +1000, "Justin Wigg"
<[EMAIL PROTECTED]> wrote, in part:
>Actually the STS and NSTS (National Space Transportation System) program
>names were dropped in the mid-late 1990s. The official program name is now
>the "Space Shuttle Program". How about that? Of course the missions still
>carry the "STS-xx" mission designations for continuity...
One learns something new every day!
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Capability of memorizing passwords
Date: Tue, 05 Sep 2000 06:13:25 GMT
On Fri, 01 Sep 2000 23:44:46 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>No question about that. But 8 ASCII characters amount
>to 56 bits only and we have them in readable character
>format that should facilitate memorizing.
It is, however, easier to memorize that same entropy in the form of a
long passphrase than a password of different kinds of characters, at
least for most people.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: 04 Sep 2000 23:44:42 -0700
[EMAIL PROTECTED] (Jonathan Thornburg) writes:
> Another patent of a fairly well-known idea:
>
> http://www.patents.ibm.com/details?&pn=US05443036__
>
> US patent #5443036: Method of exercising a cat
> filed 2 Nov 1993, issued 22 Aug 1995
>
> Abstract:
> A method for inducing cats to exercise consists of directing a beam
> of invisible light produced by a hand-held laser apparatus onto the
> floor or wall or other opaque surface in the vicinity of the cat,
> then moving the laser so as to cause the bright pattern of light to
> move in an irregular way fascinating to cats, and to any other animal
> with a chase instinct.
Note that if you do this for some other purpose, such as amusing the
human (and/or the cat), but NOT in order to exercise the cat, it
apparently does not infringe the patent.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Capability of memorizing passwords
Date: Tue, 05 Sep 2000 06:31:12 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> While it's entirely possible that people will still choose stupid
> passphrases, it's rather less likely that their "stupid" choice will be
> in an attacker's dictionary, simply because of the fact that it must be
> long. This possiblity existed when 8 letter passwords were considered,
> and can't really easily be eliminated. The closest we can come is to
> try a dictionary attack on new user's passphrases, and reject them as
> invalid if they're found.
I've never been fully convinced of the dictionary attack for anything
longer than single passwords. Despite all of the warnings about them,
I have yet to see a practical problem with "stupid" passphrases such
as english sentances.
I suppose it's reasonable to try 'Ask not for whom the bell tolls; It
tolls for thee.' before 'xx a d f;lk dckl dslhfhl lfhlshfs lhfdhlsh
hflshfsl' But then again, in most real-world examples, it's an
exercise in futility getting there. More of a Library of Congress
attack than a dictionary attack really. ;)
One interesting anecdote about dictionary attacks: I once had an
account on a distribted unix system that was limited to traditional
crypt(3) password hashes. In order to "improve" security, they
dissallowed passwords:
1. With six or fewer characters.
2. With only alphanumeric characters.
3. Comprised of two words joined by puncutaion.
4. Without letters of both cases.
5. etc
The bottom line was that the vast majority of passwords were all of
similar form, such as a capitalized word ending in a digit and
punctuated. If you eliminated control characters (because, hey it was
a distributed system and they messed up alot of terminals, not to
mention communications programs) and the list of restrictions, I
believe they managed to eliminate somewhere between 30-40% of the
entire keyspace. (The exact restrictions, and figures have faded from
memory over the years). The morals of the story are:
1. Users can be forced into picking easily guessed passwords/phrases
by over screening.
2. It's possible for overly aggressive restrictions to severly reduce
the amount of guessing needed, which hurts rather than helps.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Linux password generation script
Date: 5 Sep 2000 07:19:12 GMT
Here's a script I threw together that might be useful/interesting to
participants of this thread. It generates passphrases like "MK67CX
VWTP3E". I've been using passwords like this for a while and actually
haven't had that much trouble remembering them. The "words" by
default are 6 chars, digits and upper case letters, with certain
characters (I, 1, O, 0) not used because they look similar in some
screen fonts. If you write down the passwords, beware that "5" and
"S" can look similar in handwriting, so try to write those characters
clearly. With this 32-char alphabet (5 bits/char), two "words" gives
60 bits of entropy, which is good enough for most things passwords are
used for. Three "words" gives 90 bits which is good enough for almost
anything.
I had an earlier script that generated strings of actual english words
chosen randomly from a dictionary, but I don't think they were easier
to memorize (the phrases had to be a lot longer for the same amount
of energy), and they were slower to type (more keystrokes).
The script is Linux-specific because it uses /dev/urandom to get secure
random numbers; but you can probably come up with some substitute on
other systems.
================================================================
#!/usr/bin/perl -w
# 32-character alphabet (5 bits/char), digits and upper case letters,
# omitting "1", "0", "I", and "O", since those are easily confused.
# Hmm, "5" and "S" also look similar: maybe should use some punctuation.
# But at least 5 and S don't look similar in most screen fonts.
@alphabet = unpack ("C*", uc("abcdefghjklmnpqrstuvwxyz23456789"));
$bits_wanted = shift || 60; # minimum number of entropy bits desired
$word_length = shift || 6; # chars per word
# round up to nearest multiple of word length
$bits_per_word = $word_length * 5;
$words_wanted = int(($bits_wanted + $bits_per_word - 1) / $bits_per_word);
$bytes_wanted = $words_wanted * $word_length;
open (RAND, "/dev/urandom") || die "/dev/urandom: $!\n";
read RAND, $chunk, $bytes_wanted || die "can't read";
@bytes = unpack ("C*", $chunk);
# print in 5-char groups
for (0..$bytes_wanted-1) {
$word .= ' ' if $_ && $_ % $word_length == 0;
$word .= chr($alphabet[$bytes[$_] & 0x1f]);
}
print "$word\n";
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: RSA Patent.
Date: Tue, 05 Sep 2000 00:36:22 -0700
John Savard wrote:
> Thus, people who are
> not employed by RSADSI will indeed, even in the United States, be able
> to create software implementing that algorithm.
Yes. Actually, people in the US could always write software
that implements the algorithm. The problem only occurs when
you implement it in a communications system.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: A good MAC algorithm?
Date: 5 Sep 2000 07:51:40 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> If, for example, the MAC is being used to verify packets in a
> communication protocol, and the response to a failure is to immediately
> disconnect and display a warning to the user
Brilliant! Now I can trivially destroy all your connections.
If you immediately start communicating again with a new key, I'll simply
start attacking that key, and I'll succeed just as quickly as I would
have if you hadn't switched.
---Dan
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Crossposted-To: talk.politics.crypto
Subject: Re: RSA Patent.
Date: Tue, 05 Sep 2000 07:43:39 GMT
On 4 Sep 2000 16:28:11 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote:
>ajd <[EMAIL PROTECTED]> wrote:
>
>> I hear that the patent for the RSA encryption algorithm expires at the end
>> of this month. Does this mean that I can create commercial RSA
>> software/chips with no licence/royalty issues? Was the patent for USA only
>> or did it include Europe?
>
>The patent expires on 20 September. Some people, e.g., those who don't
>like RSA Security, or patents in general, or have been otherwise
>inconvenienced by the RSA patent, are thinking about having a party to
>celebrate.
Considering all the fuss about Senderek´s discovery of a big bug in PGP´s new
format (brought on by the new Diffie-Hellman keys), they might regard it also as
a little vindication ;-) RSA rules!
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: ISO9796 signatur format implementation
Date: Tue, 5 Sep 2000 10:05:50 +0200
Hello,
I'm looking for a (source code) implementation of ISO9796 padding and formating.
Have somone done it themselves, or have a link for me?
--
Tor
------------------------------
From: Ragni Ryvold Arnesen <[EMAIL PROTECTED]>
Subject: Re: DES weak keys in 3DES
Date: Tue, 05 Sep 2000 10:49:41 +0200
Tor Rustad wrote:
> "Gisle Sælensminde" <[EMAIL PROTECTED]> wrote in message
>
> > I so already check that k1 != k2 and k2 != k3, and rejects the key
> > if that's the case. As you say, this reduce 3DES-EDE to DES, which
> > not is desirable. By now I reject any weak or semi-weak keys
> > just in case, but I couldn't find any analysis or advise on the
> > area of weak keys. Do you know about information about this topic?
>
> Why reduce the key space?
>
> It is not clear to me how this improves the security, in fact I don't like the
> idea at all.
I completely agree with you. A weak key gives an advantage to a cryptanalyst only
if he can determine (with not too much workload) that the ciphertext has been
produced using a key from a class of weak keys. If no such distinguisher exists,
then no advantage is gained. Removing a large portion of the keys will reduce the
workload of an attack. If you feel a need to exclude large classes of keys,
consider using another algorithm instead.
-Ragni
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Capability of memorizing passwords
Date: Tue, 05 Sep 2000 11:27:41 +0200
John Savard wrote:
>
> It is, however, easier to memorize that same entropy in the form of a
> long passphrase than a password of different kinds of characters, at
> least for most people.
In my view, the problem is how to pick a 'random' passphrase
(from the space of passphrases) that is easily memorizable.
To pick a random password I can cast a die (which, because
it is short, should be memorizable in my opinion).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Capability of memorizing passwords
Date: Tue, 05 Sep 2000 11:27:58 +0200
Benjamin Goldberg wrote:
>
> While it's entirely possible that people will still choose stupid
> passphrases, it's rather less likely that their "stupid" choice will be
> in an attacker's dictionary, simply because of the fact that it must be
> long. This possiblity existed when 8 letter passwords were considered,
> and can't really easily be eliminated. The closest we can come is to
> try a dictionary attack on new user's passphrases, and reject them as
> invalid if they're found.
Tiny remark: With 8 character password one could cast a
die to determine it, so as to be fairly sure to be random.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Blum Blum Shub question
Date: Tue, 05 Sep 2000 11:27:33 +0200
Benjamin Goldberg wrote:
>
> Mok-Kong Shen wrote:
> >
> > Benjamin Goldberg wrote:
> > >
> > > I was recently looking over how the BBS public key system works, And
> > > I think I might have an idea for a different way to use it.
> > >
> > > Set up your public and private keys, using all the special
> > > considerations for choosing your two primes.
> > >
> > > The person encrypting, chooses some X and some Y, uses X as the key
> > > to some secure block cipher, and sends Z=(X^2^Y mod n) (where n is
> > > the public BBS key), and Y. The steps of BBS decryption should be
> > > able to get X from Y and Z, and so we can get the key to decrypt. Y
> > > can be a fairly small number maybe even a constant (which would mean
> > > that it wouldn't need to be sent), and it would take far fewer steps
> > > to get Z from X than would be needed for using the BBS stream cipher
> > > to encrypt the entire message directly.
> >
> > Sorry, I am confused. You said that Z and Y are sent and
> > n is public and that we can get the key (X) to decrypt.
> > But who are 'we'? Does that designation exclude the
> > opponent? Why?
>
> I should have phrased that as being "and so the decryptor can get the
> key to decipher."
I suppose that I have not stated my point clearly. I
meant that, with the same data with which the recipient
can get the key to decipher, the opponent can do the
same. (They have exactly the same stuffs available,
don't they?)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Serpent S-boxes (again)
Date: Tue, 05 Sep 2000 11:27:48 +0200
Mack wrote:
>
> I totally agree with you. But the problem with
> documentation is that what is perfectly clear to
> the writer is often totally opaque to the reader.
That's why elsewhere certain important documents are
proof-read also by persons not knowledgeable in the
field in order to assure understandability be the
users. I know one case in which a firm offered a
small reward to every error/defect that its employees
could detect in certain documents destined for the
customers.
A question of general nature is: What do the honorable
peer reviewers of documents do at places where these
are incomplete? (Closing eyes and let go?)
But the problem with ciphers like AES can be simply
stated and hence should be similarly simply solvable?
The request to be given to the authors can be like
this: Scan through the document for ALL numerical
values and show how EACH is obtained, providing
sufficient informations such that anyone can verify,
if he chooses to do so. Anyway, as long as a cipher
contains 'magic' constants that I have potentially
no way to reproduce myself, I wouldn't take the risk
to use it.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Ragni Ryvold Arnesen <[EMAIL PROTECTED]>
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: Tue, 05 Sep 2000 11:27:56 +0200
Julian Morrison wrote:
> Tor Rustad wrote:
>
> > That isn't practical, since it will be very expensive, think about the expence
> > at the bank host systems.
>
> The main expense at the bank is storing a hash of unclaimed coins; frankly this
> isn't much of a problem. A modern harddrive holds many gigabytes, costs about $100,
> and would hold millions of pending coins.
Memory for storage is probably not a big problem. All the network traffic and
processing will be much more expensive. In particular, of course, for the
clearinghouses.
> The security status of the coins, from the bank's perspective is: "that's not our
> problem".
Bad publicity, loss of the customers' trust and increased sceptisism to electronic
payment systems in general _will_ be the bank's problem.
> > If there has been a security problem, then there is no way to track it down.
> > Banks don't monitor people, but one of the basics is to be able to correct and
> > adress security and other problems with transactions.
>
> They do monitor people, and not always willingly - USA banks for example are
> required to turn over information about large movements of cash to the IRS etc -
> exactly the kind of goons this scheme is intended to confound.
Well, there you have one of the main reasons why your system will never be deployed: No
bank (no bank that I would use at least) will support a system that does not allow them
to fulfill their law-imposed duties.
-Ragni
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: DES weak keys in 3DES
Date: 5 Sep 2000 09:55:17 GMT
Tor Rustad <[EMAIL PROTECTED]> wrote:
[Checking for degenerate triple-DES keys]
> Why reduce the key space?
>
> It is not clear to me how this improves the security, in fact I don't
> like the idea at all.
I've just done some maths, and thrown it away, because it's all obvious
anyway.
Basically, the result is that the difference is negligible. It doesn't
really matter whether you include the keys or not. There may be 2^{113}
- 2^{56} of them, but that's negligible compared to the 2^{168} -
2^{113} + 2^{56} keys for which there's no better attack than Lucks'
general attack on triple encryption. The expected effort doesn't change
in any meaningful way whether you discard the degenerate keys or not.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Blum Blum Shub question
Date: 5 Sep 2000 10:03:25 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> I suppose that I have not stated my point clearly. I meant that, with
> the same data with which the recipient can get the key to decipher,
> the opponent can do the same. (They have exactly the same stuffs
> available, don't they?)
No. The recipient has the factors of the modulus, which enables him to
compute square roots.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: 5 Sep 2000 10:06:51 GMT
Eric Smith <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Jonathan Thornburg) writes:
>
> > Abstract:
> > A method for inducing cats to exercise consists of directing a beam
> > of invisible light produced by a hand-held laser apparatus onto the
> > floor or wall or other opaque surface in the vicinity of the cat,
> > then moving the laser so as to cause the bright pattern of light to
> > move in an irregular way fascinating to cats, and to any other animal
> > with a chase instinct.
>
> Note that if you do this for some other purpose, such as amusing the
> human (and/or the cat), but NOT in order to exercise the cat, it
> apparently does not infringe the patent.
It doesn't even work very well. The cats I've met all prefer chasing
after more tangible things, such as bits of string. I think that the
problem is that you can't give a spot of laser light a good chew once
you've caught it.
-- [mdw]
------------------------------
** 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
******************************
