Cryptography-Digest Digest #915, Volume #8 Sat, 16 Jan 99 17:13:05 EST
Contents:
Re: Too simple to be safe ("Kazak, Boris")
Re: Metaphysics Of Randomness ("Kazak, Boris")
Is speed of public-key algorithms important? (Charles Blair)
Re: Cayley-Purser algorithm? ([EMAIL PROTECTED])
Re: Is speed of public-key algorithms important? (Bruce Schneier)
Re: Cayley-Purser algorithm? (Paul L. Allen)
Re: Too simple to be safe (Paul Rubin)
Re: New Twofish Source Code Available (Uri Blumenthal)
Re: Too simple to be safe ("Kazak, Boris")
Re: Cayley-Purser algorithm? (Anthony Naggs)
Re: Cayley-Purser algorithm? (D. J. Bernstein)
Re: Export laws (wtshaw)
Re: On leaving the 56-bit key length limitation ([EMAIL PROTECTED])
Re: Too simple to be safe ("almis")
Re: New Twofish Source Code Available (Daniel James)
Re: Cayley-Purser algorithm? (David Hamilton)
----------------------------------------------------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sat, 16 Jan 1999 10:57:41 -0500
Reply-To: [EMAIL PROTECTED]
almis wrote:
>
> For a symmetric (shared) key cryptosystem there are many complicated
> schemes.
> I thought of one that seems too simple to be safe.
>
> The basic idea is the conjecture that the square root of a prime number is
> always irrational.
>
> If the above is true then ...
>
> 1. Generate a large prime p. (the shared key)
>
> 2. Calculate the irrational number n = SQRT(p)
>
> 3. N is the fractional part of n. that is N = n - Floor(n)
> N is a sequence of non-repeating numbers.
>
> 4. Chose an index pointer, x.
>
> 5. Encode the message with N starting at x.
>
> 6. Send the encoded message and the pointer.
>
> 7. Decode the message by recalculating N and start at x.
>
> That's it!
>
> The concept begs two questions:
> (1) How difficult is it to find the square root of a prime to an arbitrary
> length?
> (2) Given a sequence of digits of a known length and starting at a given
> position how difficult would it to be to recover the prime number that
> generated it?
>
> Fud for thought ...al
=============================
And here is a scheme that I practically use in communication with
my son in Moscow.
1. We both have the same long (~150 KB) random file.
2. When I need to send a message, I open the random file in the
hex editor and select N bytes starting at offset S.
3. The selected string of random bytes is used as a key to a
symmetric cipher.
4. The E-Mail message consists of words:
"use S, N",
then follows the attached file with the message.
5. On the receiving end the sequence of operations is obvious.
Like that the information about the key is communicated in the open
text, and the key is never reused. No digital signatures, no CA's.
Any comments? Respectfully BNK
------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Sat, 16 Jan 1999 11:23:48 -0500
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> From a *metaphysics* and *theorical* point of view, and from
> my point of view, randomness dosent exist. What we usually
> call "a random phenomenon" is a phenomenon which obey to
> unknown or unpredictable rules.
>
> My opinion is all phenomenon obey to rules even if the rules
> arent currently known. ok it is just my opinion and i dont have proofs.
>
> Under this assumption, all the security protocols which required
> randomness (e.g. OTP and more generally any key generation) are
> not secure. You can just hope that the attacker dosent know or
> can't predict the rules which produce your randomness.
>
> in pratice, this kind of hope is not risky but in theory it is.
====================================
There is also another detail which is often overlooked in such
discussions. The systems which produce apparent randomness fall
in one of two broad categories - with memory amd without memory.
All PRNG's are systems with memory, contrary to the dice, roulette
and radioactive decay. The concept of correlated length gives an
idea of how far does the influence of a particular event extend.
So in my understanding, any system with equiprobable outcomes
and without memory will produce "true" randomness, in the sense
that any particular outcome will not depend on the past and will
not influence the future. This seems to be a very practical
approach, for cryptography and other applications.
Respectfully BNK
------------------------------
From: [EMAIL PROTECTED] (Charles Blair)
Subject: Is speed of public-key algorithms important?
Date: 16 Jan 1999 18:08:34 GMT
My understanding is that PGP and other protocols do the following:
(1) Create a cryptographically strong hash of the plaintext. The
size of the hash does not depend on the size of the plaintext.
(2) Use the hash to create a key for a PRIVATE-key system, such as
IDEA or something like DES. Encrypt the plaintext using this system.
(3) Use the public-key system only to create an encryption of the
private key.
(4) Send the ciphertexts created in (2) and (3).
If I have this right, step (3) works on a plaintext of a size that
does not depend on the size of the original message. This suggests
that efficiency of step (2) is much more important than step (3).
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cayley-Purser algorithm?
Date: Sat, 16 Jan 1999 16:45:59 GMT
In article <[EMAIL PROTECTED]>,
Kent Briggs <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > > If all goes well, you can then consider applying for a US patent.
> >
> > Sorry. Once the method has been published, it CAN NOT be patented in
> > the US.
>
> You have up to one year to file after initial publication. There was a big
> stink made about the Diffie-Hellman patent because it was filed over a year
> past initial publication.
I have been through 2 patent applications in the last 6 months. And will
probably go through 2 more in the coming year.
You MUST file at least a provisional application before publishing. Once you
file a provisional application you have a year to file the full application.
But you can not publish first.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Is speed of public-key algorithms important?
Date: Sat, 16 Jan 1999 18:41:47 GMT
On 16 Jan 1999 18:08:34 GMT, [EMAIL PROTECTED] (Charles Blair)
wrote:
> My understanding is that PGP and other protocols do the following:
>
> (1) Create a cryptographically strong hash of the plaintext. The
>size of the hash does not depend on the size of the plaintext.
>
> (2) Use the hash to create a key for a PRIVATE-key system, such as
>IDEA or something like DES. Encrypt the plaintext using this system.
>
> (3) Use the public-key system only to create an encryption of the
>private key.
>
> (4) Send the ciphertexts created in (2) and (3).
>
> If I have this right, step (3) works on a plaintext of a size that
>does not depend on the size of the original message. This suggests
>that efficiency of step (2) is much more important than step (3).
Correct, although it depends on the size of the message. If the
public key operation is about 500 times as slow as the block cipher,
than (for DES or IDEA) a 4K message will be 50% block encryption and
50% public key encryption.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Paul L. Allen)
Subject: Re: Cayley-Purser algorithm?
Date: Sat, 16 Jan 1999 18:10:13 +0000
Reply-To: [EMAIL PROTECTED]
In article <77qfo5$lv7$[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Kent Briggs <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > > > If all goes well, you can then consider applying for a US patent.
> > >
> > > Sorry. Once the method has been published, it CAN NOT be patented in
> > > the US.
> >
> > You have up to one year to file after initial publication. There was a big
> > stink made about the Diffie-Hellman patent because it was filed over a year
> > past initial publication.
>
> I have been through 2 patent applications in the last 6 months. And will
> probably go through 2 more in the coming year.
>
> You MUST file at least a provisional application before publishing. Once you
> file a provisional application you have a year to file the full application.
> But you can not publish first.
Some people may want a broader coverage than just the US. In which case,
it's worthwhile noting that in many countries any prior published material
disbars you from filing a patent. In other countries the rule is don't
publish until after you have the patent.
--Paul
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Too simple to be safe
Date: Sat, 16 Jan 1999 20:51:58 GMT
In article <[EMAIL PROTECTED]>, Kazak, Boris <[EMAIL PROTECTED]> wrote:
>And here is a scheme that I practically use in communication with
>my son in Moscow.
> 1. We both have the same long (~150 KB) random file.
> 2. When I need to send a message, I open the random file in the
>hex editor and select N bytes starting at offset S.
> 3. The selected string of random bytes is used as a key to a
>symmetric cipher.
> 4. The E-Mail message consists of words:
> "use S, N",
> then follows the attached file with the message.
> 5. On the receiving end the sequence of operations is obvious.
>
>Like that the information about the key is communicated in the open
>text, and the key is never reused. No digital signatures, no CA's.
>
> Any comments? Respectfully BNK
If your symmetric cipher (about which you say nothing) is any good,
then your security is good and fancy method of key setup (like the
150 kbyte file) won't make it any better.
If your symmetric cipher (about which you say nothing) is not good,
then your security is bad and fancy method of key setup (like the
150 kbyte file) won't make it any better.
Either way, the 150 kbyte file and the S,N scheme don't seem to help you.
The symmetric cipher is a much more important issue.
Also, I don't mean to be disrespectful in saying this, but the nature
of cryptography is that if you don't know exactly what you're doing,
it's very easy to make a mistake that can compromise your security and
get you in a lot of trouble.
So I think you're much better off using something like PGP, which
is widely available and has been heavily analyzed by a lot of people.
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: New Twofish Source Code Available
Date: Thu, 14 Jan 1999 17:14:16 -0500
Reply-To: [EMAIL PROTECTED]
Bruce Schneier wrote:
> >Bruce Schneier wrote:
> >> We have new Twofish source code--reference C, optimized C, and
> >> ASM--that reflects the improvements we've made.
> >
> >But no Java code improvements yet?
>
> We've had Java since the beginning. It was one of NIST's
> submission requirements.
Bruce, I know that you've had Java for a long time. You also
had C code from the very beginning (I know - I ftp'ed it :-).
But recently you posted that you got NEW IMPROVED source
code for C and Asm - so my question is: are there
any IMPROVEMENTS to Java code yet, similar to
the C code improvements maybe?
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sat, 16 Jan 1999 16:03:32 -0500
Reply-To: [EMAIL PROTECTED]
almis wrote:
>
> You have, in effect, the most secure of secure systems.
> The formidable OTP.
> Simple and effective.
=======================
Sorry, we don't use it as OTP (although we could), we just select at
random 20-25 bytes to be used as a key to a conventional block cipher.
=======================
> However the random file should truly be random, don't resuse any of the key,
> and the key must be at least as long as the sum of your messages.
> I don't find these requirements a great impediment.
=======================
When I'll become wealthy, I'll purchase a CD recorder,
go to the beach with a microphone and generate a 650 MB random file
from the sounds of the surf - for the rest of my lifetime...
=======================
> BTW. Your sending S and N in the clear is correct...
> A crypto razor is: 'That which cannot be hidden well, should not be hidden
> at all !'.
> The greatest weakness, IMHO, is the need for the secure channel to share the
> key.
Transport it on camel's back.
>
> ...al
> (P.S.) No, I'm not a 16 year old girl... I'm a 52 year old man! (i guess
> this blows my shot at fame)
You, kid.. I'm 60! Respectfully BNK
------------------------------
From: Anthony Naggs <[EMAIL PROTECTED]>
Subject: Re: Cayley-Purser algorithm?
Date: Sat, 16 Jan 1999 21:05:38 +0000
After much consideration decided to share these wise words:
>
>You MUST file at least a provisional application before publishing. Once you
>file a provisional application you have a year to file the full application.
>But you can not publish first.
Whether Sarah Flannery's entry to the science competition counts as
publishing rather depends on the rules of the competition. Certainly
there is no sign so far that it has had any wider circulation than the
competition judges. (And Baltimore Technologies for whom she was
working when introduced to Dr Michael Purser's original work on the
idea.)
For what it's worth the most detailed article I've seen was Tim
Radford's in The Guardian on Thursday.
--
BAD COMPUTER! That's my registry file you've trashed.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Cayley-Purser algorithm?
Date: 16 Jan 1999 21:09:23 GMT
John Savard <[EMAIL PROTECTED]> wrote:
> That was my original reaction: but after referring to your book, it
> seems that public key schemes that don't require exponentiation to the
> extent of RSA are possible, as some already exist - that of Rabin, the
> improvement of Williams, and the two-dimensional version of Koyama.
Rabin-Williams signature verification uses only one modular squaring,
and a modification to the system speeds it up even more---but signing
still requires a full modular exponentiation.
---Dan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Export laws
Date: Sat, 16 Jan 1999 14:10:21 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Bruce Schneier) wrote:
>
> When someone (presumably outside the US) tries to download the file,
> he is not doing anything illegal. (Unless, of course, he lives in a
> country that believes US laws apply on non-US soil.) The owner of the
> website is exporting the software (we think...this has never been
> tested in court. I believe he is not exporting, but that's just me.)
>
> >If someone in the US downloads the file from the US server,
> >and sent me some money for it, would I be breaking the law?
>
> Since you live in the UK, you should be concerned about UK law.
> (Again, if the UK decides that US law applies on UK soil, this may be
> different. But countries are usually pretty particular about making
> their own laws.) I don't see any problem with the above, but you
> should check with someone who understands UK law better.
>
I think I see what he may be thinking: a person OUTSIDE of the US might
choose to have a website IN the US. An ISP might very well not consider
that the owner of a site that it hosts resides outside of the country, and
might even fooled by a maildrop as a stateside address.
If encryptive software is exported from the such a site, then who is
responsible? To put liability on the ISP for all files that might be on
websites would be news to many of them. To put the liability of a foreign
national who perhaps never set foot in the US might be difficult. To put
the burden on the ISP to verify residency and citizenship would require
some legislation.
The only practical thing to do under those circumstances would be for the
government to keep an eye out for abuses, and order ISP's to do something
about such files when discovered by them or the government.
Meanwhile, it seems that foreign nationals in coordination with lax ISP's
could put all sorts of files online that would otherwise get someone in a
heap of trouble.
--
Crypto with attitude....
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On leaving the 56-bit key length limitation
Date: Sat, 16 Jan 1999 18:17:53 GMT
In article <77ora0$d5o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> Here are issues I've been speaking about:
>
> * Presenting an adversary with less ciphertext than the unicity
> distance of the secrecy system does _not_ ensure that he can
> obtain no useful information from the ciphertext.
>
Bryan:
One may try to be quaint and say that just detecting ciphertext is a useful
information that the attacker can obtain -- however, I may send bogus messages
with random letters once in a while and even that modicum is not granted.
However, this is all besides the point of my original e-mail. To which I would
like to refer to. Our dialogue was:
|Ed Gerck wrote:
|> 1. First, I wish to point out that Theoretically-Secure Cryptographic
|> Systems (hereafter TSCS) do not depend on key-length for secrecy --
|> in their design region. In fact, Shannon already showed 50 years ago
|> that a TSCS does not depend on key-length when one works within the
|> system's "unicity distance".
|Bryan replied:
|Staying within the unicity distance only ensures that
|more than one possible decryption exists. A cryptanalyst
|may still get large amounts of useful information.
A system that carries a one-bit message "yes" or "no" and is encrypted by XOR
with a one-bit secret-key is theoreticallt secure. Even though the attacker
may know that I can send either "yes" or "no". So, in its design region of
only one bit, the system as I exemplified is theoretically secure. The
attacker cannot decide what was sent.
This contradicts what you replied at the least possible level -- one bit of
key-length, which was the design region.
Perhaps, my four words "in their design region" went unnoticed by you. But,
they are clearly there -- also implicity, when I wrote "within the system's
"unicity distance". Again, your comments must not ignore what you want to
comment .. the text as I wrote it.
The bottomline here is that key-length is NOT what can define if a system is
theoretically secure or not -- but its unicity. A system can have very low
key-length, in fact just one bit, and be theoretically secure. But, I guess I
said that already ;-)
|Ed Gerck wrote:
|> So, the factor we need to work on in
|> order to protect our privacy is "unicity distance" -- not key length.
|Bryan replied:
|No, that doesn't follow.
I guess it is clear it does follow -- unless you want me to repeat the above
yet once more, which I will do:
The bottomline here is that key-length is NOT what can define if a system is
theoretically secure or not -- but its unicity. A system can have very low
key-length, in fact just one bit, and be theoretically secure. But, I guess I
said that already ;-)
> * If ciphertext contains no information about the corresponding
> plaintext, we have perfect secrecy. Perfect secrecy is a strictly
> stronger condition than lack of unique solution.
You are venturing into a slippery slope. Of course, the ciphertext must
contain information about the corresponding plaintext, otherwise you could
not decipher it. The question is how much can you gather from it.
However, you will NOT find ONE occurrence of the word "perfect" or "perfect
secrecy" in my message -- nor in the full text at
http://www.mcg.org.br/unicity.txt. So, I must assume you are confusing
"theoretically secure systems" with "perfect secrecy".
And, I guess that you are now reading more than what I wrote, while before
you were reading less -- as when you missed that I wrote my four words "in
their design region". Both inaccuracies lead to slippery slopes....and, they
have nothing to do with what I wrote. Again, I appreciate your comments as I
appreciate any comment, but I believe they are more useful the more they
would pertain to the text I actually wrote and not to a fictional text with
more than what was written, or less.
Unless, of course, you are getting this over UDP and not TCP ;-)
>
> * The unicity distance of ASCII-encoded English under DES is greater
> than one DES block.
As I prove in http://www.mcg.org.br/nrdes.txt and use in
http://www.mcg.org.b/unicity.txt, DES unicity cannot be larger than one block
because DES is not a random cipher over more than one block. If you disagree,
plas contradict my proof in nrdes.txt.
Accordindgly, I observed that the basic assumption used by Shannon to define
and calculate unicity is not valid over more than one block of DES. To say
otherwise is to use a formula where it is not valid -- rubbish in, rubbish
out.
So, what you are saying contradicts the application region of the formula --
nothwithstanding the good company you may be with when you cite that. So, this
is more of a "literature mistake" and I undesrtand you were just perfunctorily
requoting.
Further, in the unicity. txt paper, I noted that to break into a DES key one
is perhaps not limited by the least amount of "Distinguished readable and
valid text" one can recognize -- which is Unicity-1 at 5-bytes.
The idea is that the least amount of "Obscure readable and valid text"
should already be enough, when compared with "Obscure garbage". In
other words, one just needs to identify with some degree of success
(which can then be confirmed by a second check with more bits in the
same block) whether English is probably present or not. One does not
need to know which English words were used, in order to break into the
key. Of course, once the key is known, any message that uses that key
can be directly deciphered -- irrespective of message length.
This leads to the concept of Unicity-5 -- which is 3 bytes for DES.
Thanks for your comments.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck [EMAIL PROTECTED]
http://novaware.com.br
--- Meta-Certificate Group member -- http://www.mcg.org.br
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "almis" <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sat, 16 Jan 1999 13:56:13 -0600
Kazak, Boris wrote in message <[EMAIL PROTECTED]>...
|=============================
|And here is a scheme that I practically use in communication with
|my son in Moscow.
| 1. We both have the same long (~150 KB) random file.
| 2. When I need to send a message, I open the random file in the
|hex editor and select N bytes starting at offset S.
| 3. The selected string of random bytes is used as a key to a
|symmetric cipher.
| 4. The E-Mail message consists of words:
| "use S, N",
| then follows the attached file with the message.
| 5. On the receiving end the sequence of operations is obvious.
|
|Like that the information about the key is communicated in the open
|text, and the key is never reused. No digital signatures, no CA's.
|
| Any comments? Respectfully BNK
You have, in effect, the most secure of secure systems.
The formidable OTP.
Simple and effective.
However the random file should truly be random, don't resuse any of the key,
and the key must be at least as long as the sum of your messages.
I don't find these requirements a great impediment.
BTW. Your sending S and N in the clear is correct...
A crypto razor is: 'That which cannot be hidden well, should not be hidden
at all !'.
The greatest weakness, IMHO, is the need for the secure channel to share the
key.
...al
(P.S.) No, I'm not a 16 year old girl... I'm a 52 year old man! (i guess
this blows my shot at fame)
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: New Twofish Source Code Available
Date: Sat, 16 Jan 1999 20:05:39 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Mr. Tines wrote:
> .... the IDEA code from PGP 2.6ui
> compiled debug under BC++5.02 only ran 3 times faster than
> a non JIT-ed Java version of the same code (using the test
> harness there) in JDK 1.1.6.
>
Comparing debug C code with non-JIT-compiled Java bytecode is hardly a
fair or meaningful exercise, is it? How does the optimized C compare
with JIT compiled bytecode? I'd expect rather more of a difference.
Cheers,
Daniel James
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Cayley-Purser algorithm?
Date: Sat, 16 Jan 1999 20:32:22 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> Bruce you say that because of your prejuiduces. I hope because
>she has not been brain washed by some of the so called modern
>books on crypto that she was able to strike out on her on
>instead of following so called phony experts in the crypto
>field.
Ignorant people often condemn books and others who know more than them. Such
people can only deal with their own lack of success by hitting out at others.
> Of course this is only a hope and I fear it may be
>wrong but I keep hoping anyway.
> But the sad truth of the matter is if was good I think the
>NSA would have been able to keep the lid on it. Of course
>they still have time since the method has yet to see the light
>of day on the net.
More drivel about the USA NSA being more powerful than it is.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNqDUtMo1RmX6QSF5AQFKOQf/SdEs1MABIRIbj7yDCe/aUZiahu8JRxBJ
Qt64OvjMDtuFvULOd4vGnhlfm0rHQ9xFrIkfrvcfuj7BmqMr6DZYElrGx1gBkcWp
2URv7RuILIm8PIVZJz4essxIchQPws59UGSi80mZi2uyrsbOhmNXOSPvp/ZsIj34
JJEnKB83QkDKqjNyjAmSCWx3p+p4CZ8MaKw9ApuCNVJG/GrZLbC4eF6dsRSUI38e
JPT0aKI08czCPnPJNSummR//S+hTEh3SawHeh5nS4hI4rX4Em7jEEC65B+nz+9fp
GvaWwj5iybQV/ptYFeKCcCXjORxtb5Yup8daMQc8KmgPOOXHNG9yvQ==
=lgLj
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
