Cryptography-Digest Digest #63, Volume #13 Wed, 1 Nov 00 00:13:01 EST
Contents:
Re: BENNY AND THE MTB? (Tom St Denis)
Re: Rijndael file encryption question. (Tom St Denis)
Re: Rijndael Key Schedule ("Scott Fluhrer")
Re: RSA Multiprime (Tony L. Svanstrom)
Re: Searching for a good PRNG ("Scott Fluhrer")
Re: Searching for a good PRNG (David Schwartz)
Re: Padding scheme? (SCOTT19U.ZIP_GUY)
Re: Legal reqiurements for CCTV watermarking ([EMAIL PROTECTED])
Re: End to end encryption in GSM (David Wagner)
Re: Legal reqiurements for CCTV watermarking ("Trevor L. Jackson, III")
Re: Is RSA provably secure under some conditions? (David A Molnar)
Re: A new paper claiming P=NP (Eric Cordian)
Re: Psuedo-random number generator (David Hopwood)
Re: XOR based key exchange protocol - flawed? (David Hopwood)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Wed, 01 Nov 2000 01:50:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] wrote in <8tncsb$e7i$[EMAIL PROTECTED]>:
>
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >
> >Let's start with the obvious stupidities.
> >1) A Rijndael block of "1 byte"
> >Truth : Rijndael is a 128-bit block cipher, there is not way to make
it
> >generate a single byte output that is decryptable
>
> That my friend is where your full of shit. Take a look
> at Matts code or is it easyer to just spout you unknowledgeable
> crap. Matt compresses and use Rijndael. THe individual blocks
> that Rijndael are not one byte. But with proper use the input
> or output of the combined compression encryption problem can.
> LIke I said dunger head try it. You will find you are dead wrong.
Why do you post in sci.crypt anyways?
Your assertion that Matt's cryptosystem is the best in the world is
unfounded. Why not prove how good it is before trying to be a jerk
about it?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Rijndael file encryption question.
Date: Wed, 01 Nov 2000 01:52:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (mac) wrote in <8tngud$2gp9$[EMAIL PROTECTED]>:
>
> >Hello!
> >
> > I have the same problem and I posted it with subject "Newbie
about
> >Rijndael" (10/31/00).
> >I was directed to Matt Timermanns code which is great. There are some
> >other, not so good but simpler methods. For example, if you have two
> >byte string to encrypt (block size = 16b) you can fill the last two
> >bytes of a block with your string and put the number of 'good' bytes
> >(two in this example) in the first byte of a block. You can fill the
> >bytes between(2-14)with '0' for example. When this block is decrypted
> >you read the first byte and you know the length of the 'good' string
> >from the end of the file.
> > There are many different methods as there are many smart people
out
> >there. But the main point here is the question of standard. If 'Bob'
who
> >is encrypted data and the key being sent to, doesn't have the same
> >implementation of Rijndael (and the problem we discuss is solved
> >differently) he won't be able to decrypt parts of the text that
didn't
> >fit in the size of a block. So, I think we are looking for the
standard
> >technique (if there is some).
>
> Get Bob a copy of Matts code.
Why? What is so great about Matts code?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Rijndael Key Schedule
Date: Tue, 31 Oct 2000 17:13:12 -0800
Simon Johnson <[EMAIL PROTECTED]> wrote in message
news:8tnmsc$n0f$[EMAIL PROTECTED]...
> In article <8tmffc$23fo$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Trish Conway) wrote:
> >
> > In the Rijndael key schedule the first subkey is just a copy of the
> userkey(for a 128 bit userkey). Could the following scenario be
> interpreted as a weakness : Say the subkeys are generated in a black
> box in hardware and an unauthorised person breaks into the black box
> and obtains the subkeys. They now have the userkey and can go to
> another black box and input the userkey and impersonate a legitimate
> user(supposing that the userkey is distruted to a number of users all
> using a central host).
> >
> >
> What you've just realised is how block ciphers are attacked.
> Differential and linear cryptanalysis works to recover a round-key(s)
> and break the cipher that way. This isn't a weakness, since its generic
> to every block-cipher, it can't really be avoidided.
Actually, it can be. Some block ciphers make the key scheduling itself be
cryptographically strong, in the sense that given a round subkey, it's
computationally difficult to get other round subkeys, or the master key
itself. However, these designs are usually in conflict with another
desirable property of block ciphers, which is to have key agility.
--
poncho
------------------------------
Subject: Re: RSA Multiprime
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Wed, 01 Nov 2000 02:20:06 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Bob Silverman wrote:
> >
> > [EMAIL PROTECTED] (DJohn37050) wrote:
> > > The original RSA patent that just expired mentioned the possibility of
> > > using more than 2 primes. Draw your own conclusions about the Compaq
> > > multiprime patent. Bob Silverman, RSA Labs, at the last ANSI X9F1
> > > meeting said he thought the Compaq patent would be declared invalid.
> >
> > I said no such thing. I did NOT say that it *would* be invalidated, I
> > said that it *could* be easily challenged. Because of the way our laws
> > work, one can't just go into court and say "I challenge this patent".
> > One must VIOLATE the patent, then have the owner sue you over the
> > violation. It is a protracted and messy and expensive process.
> >
> > Any challenge is almost certain to succeed. But one must weigh the cost
> > of the challenge against the cost of licensing fees. This is true all
> > the time. Many patents are easier to accede to than to fight.
>
> This clearly indicates the disadvantage of not having
> a public review period for US patents.
Oh, I was trying to figure out how the heck the crypto-community could
let that one pass without alerting anyone that wants to listen that
there was nothing (more or less) new about it.
Is it like that with all patents, that once the public finds out about
them the are already set in stone and you need to get sued to be able to
challenge it? I have a hard time believing that, it simply sounds too
stupid to be true.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---���---���-----------------------------------------------���---���---
\O/ \O/ �99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Date: Tue, 31 Oct 2000 17:19:48 -0800
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8tl2h6$gj0$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > : [EMAIL PROTECTED] wrote:
> > :> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > :> : Tom=E1s?= Perlines 1Hormann <[EMAIL PROTECTED]> wrote:
> >
> > :> :> I am searching for a good PRNG in software, preferrable for
> FREE.
> >
> > [...]
> >
> > :> :> Does anybody know a good URL???
> > :>
> > :> : http://www.fourmilab.ch/hotbits/generate.html
> > :>
> > :> : :-)
> > :>
> > :> That may be a good URL - but to save people visiting it
> > :> unnecessarily, it is linked to a hardware RNG which you can access
> > :> over the web.
> >
> > : What is your point?
> >
> > I thought I had expressed it clearly. What is in need of
> clarification?
>
>
> Exactly why are hotbits not a good source of random bits?
Hotbits may be an excellent source of random bits (of course, it's not a
"good PRNG in software")
Hotbits running on an untrusted computer (I certainly don't know who's
running www.fourmilab.ch), and who sends those random bits over the Internet
in the clear, is, shall we say, less than perfectly secure...
--
poncho
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Date: Tue, 31 Oct 2000 18:51:29 -0800
Scott Fluhrer wrote:
> Hotbits running on an untrusted computer (I certainly don't know who's
> running www.fourmilab.ch), and who sends those random bits over the Internet
> in the clear, is, shall we say, less than perfectly secure...
Of course, if they sent them securely, there'd be less of a problem.
The only problem is, in order to receive them securely, you'd need to
generate a public/private key pair, for which you'd need
cryptographically strong randomness. A chicken and egg problem.
DS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Padding scheme?
Date: 1 Nov 2000 03:01:36 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>: Tim Tyler wrote:
>:> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>:> :> [EMAIL PROTECTED] (Benjamin Goldberg) wrote:
>
>:> :> >After having read some other recent stuff on this group discussing
>:> :> >padding, I realize that a trojan horse type program could use the
>:> :> >random padding as a subliminal channel. To avoid this, the
>:> :> >padding should, instead of being random, be the first bytes and
>:> :> >bits from a cryptographicly secure hash of the message. [...]
>
>[snip]
>
>:> : Although it's true that using bits from a hash, rather than bits
>:> : from a TRBG, does create a bijective mapping from the set of
>:> : messages whose lengths are multiples of 8 bits to the set of
>:> : messages whose lengths are multiples of 128 bits [...]
>:>
>:> s/true/false/
>:>
>:> You've just added a redundant section to the message. A bit like
>:> cutting the first few characters and pastuing them onto the end of the
>:> file. No bijective map is likely to be found there.
>
>: Note that the domain and range are not the same. The domain is the set
>: of messages whose lengths are integral numbers of 8-bit bytes. The
>: range is the set of messages whose lengths are integral numbers of
>: 128-bit blocks. If the hash of the message is used as the source of
>: 'random' padding bytes, then each message in the domain maps to
>: precisely one message in the range. Furthermore, the inverse function,
>: which strips padding, maps each message in the range of the padding
>: function to one and only one message in the domain. Does not this
>: padding scheme describe a mapping that is one-to-one and onto?
>
>No. You're correct that each message in the domain maps onto one and only
>one object in the range.
>
>However you are not correct that each message in the range maps
>onto one and only one message in the domain.
>
>To illustrate this, I'll present an example, using a dumbed down,
>trivialised version of your padding scheme (which will hopefully
>nonetheless contain sufficient elements to illustrate the point).
>
>Consider the mapping between:
>
>[Message] and [Message|128 bit hash of the message] (where "|" indicates
>a stratigtforwards appending of the data).
>
>Is this mapping a bijection? No. Proof?
>
>To recover the [message] from the combined [message|hash],one simply
>strips off the last 128 bits.
>
>Obviously this stripping is many to one operation.
>
>101010011|1111100 gets mapped to 101010011.
>101010011|0101010 *also * gets mapped to 101010011.
>
>Your system is much the same. A number of 128-bit granular objects map to
>the same original 8-bit file (or some of them don't map to anything and
>do something like generate errors).
>
>:> : there is no significant difference in security between the original
>:> : 1-to-many mapping and the hash-based 1-to-1 mapping.
>:>
>:> You don't rate that ability to reject keys on the basis of their
>:> having appended padding in the form of hash data (that doesn't
>:> match the contents of the message) as a security risk?
>
>: Consider that the entire message must be decrypted to be able to reject
>: a key. There's a tradeoff... either use a RBG to create the padding,
>: and risk the possibility of a subliminal channel being snuck in (a
>: trojan horsed encryption program) by your opponent, or use hash bits,
>: which allow rejection of keys. [...]
>
>These are (more or less) the only options if you are using random padding.
>
>There's an alternative (which David advocates) - which is not using any
>padding at all and simply applying a bijective map between the set of
>8-bit files and the set of 128-bit ones.
>
>This method has a number of attractions - however, I believe it
>has an imperfection of its own.
>
>There's another alternative to padding - which is to use an encryption
>algorithm that can cope with variable size messages, without padding them.
>
And that is just what scott16u and scott19u do. They treat the
whole file as a single block.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Legal reqiurements for CCTV watermarking
Date: Wed, 01 Nov 2000 03:26:28 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Andrew Cogger wrote:
[snip]
>
> Typically the trust of a disinterested third party is used to prevent
> after-the-fact forgeries. This can be as simple as generating hash
> values for the protected data and recording those values with a third
> party or publishing them in a forum of record. The hashes are usually
> chained so that forging a value would invalidate all subsequent values.
>
>
Thanks for your reply!!
The application I am investigating involves the use of CCTV in a public
transport system, so the whole process of storing integrity data must be a
closed loop.....but your suggestion is interesting...
Thanks
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: 1 Nov 2000 03:54:04 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Marcus AAkesson wrote:
>You are much better and cheaper off buying the product off the shelf.
>There is a GSM phone with military-class end-to-end encryption
>available, the Swedish Tiger. Cost is about USD 4000 / handset.
Yes, but:
1. How do you know whether it is secure or not?
The GSM consortium also claimed that their cellphones were secure,
but things didn't turn out quite so well for them.
I see no technical details on the web site, nor any security reviews,
nor indeed anything else to boost confidence in their product, so why
should we believe the Sectra folks? Is there any reason to believe
the Tiger should be treated as anything other than a device of unproven,
unknown security?
2. Lest you point to the purchases by the US DoD, let me first say this:
When I looked ago, the web site said that there are two different
products, one for military users and one for non-military users.
Even if we accept for the sake of argument that the military product
has excellent security, that says nothing about the security of the
commercial product.
------------------------------
Date: Tue, 31 Oct 2000 23:14:42 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Legal reqiurements for CCTV watermarking
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> > Andrew Cogger wrote:
> [snip]
> >
> > Typically the trust of a disinterested third party is used to prevent
> > after-the-fact forgeries. This can be as simple as generating hash
> > values for the protected data and recording those values with a third
> > party or publishing them in a forum of record. The hashes are usually
> > chained so that forging a value would invalidate all subsequent values.
> >
> >
>
> Thanks for your reply!!
>
> The application I am investigating involves the use of CCTV in a public
> transport system, so the whole process of storing integrity data must be a
> closed loop.....but your suggestion is interesting...
If you need to certify a recording you have a chain-of-custody issue. You can
reduce the items requiring custodial care to to something that fits on a
floppy every week or month by creating signed hashes. Then you just deposit
the floppy with your department's OPR and the actual records require no
special handling.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: 1 Nov 2000 04:02:39 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
> Bryan Olson wrote:
>>David Wagner wrote:
>>> Roger Schlafly wrote:
>>> >Which is why these folks shouldn't be claiming that they have proofs.
>>>
>>> Is it acceptable to claim you have a proof when what you really mean
>>> is that you can prove it secure under the assumption that factoring is
>>> hard?
>>
>>How about: "depends on the audience"? The goal is to
>>communicate efficiently without deceiving people. When
>>talking to cryptologists who are familiar with these
>>reductions, "proof" is appropriate. If they want to know
>>what problem was reduced to violating what security
>>property, they'll ask.
> That's a fair answer! I like that position.
> And, I'd argue that the same principles should apply to
> stating results in the random oracle model, as well.
Well, every paper I've ever seen which was written since 1994
explicitly states the random oracle assumption if used. There
are papers before 1994 which use it and tend to state that
"we assume a random function", but it didn't have a name
until Bellare and Rogaway.
------------------------------
From: Eric Cordian <[EMAIL PROTECTED]>
Subject: Re: A new paper claiming P=NP
Crossposted-To: comp.theory,sci.math,sci.op-research
Date: Wed, 01 Nov 2000 04:41:44 GMT
In comp.theory Timothy Chow <[EMAIL PROTECTED]> wrote:
>>The people supposedly giving the prize made a not-quite-trivial mistake
>>regarding Poincare's Conjecture on their site.
> What is this mistake?
One mistake is that while the .pdf file correctly describes the
conjecture, the layman's blurb incorrectly describes it to be a
demonstration that S(3) is simply connected.
It is, in fact, the statement that a 3-manifold which is homotopy
equivalent to S(3) is homeomorphic to S(3).
--
Eric Michael Cordian 0+
O:.T:.O:. Mathematical Munitions Division
"Do What Thou Wilt Shall Be The Whole Of The Law"
------------------------------
Date: Wed, 01 Nov 2000 01:50:39 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Psuedo-random number generator
=====BEGIN PGP SIGNED MESSAGE=====
Rob Warnock wrote:
> Terry Ritter <[EMAIL PROTECTED]> wrote:
> +---------------
> | First, I am unaware of any parts which have specified and therefore
> | predictable metastable operation.
> +---------------
>
> You must not have looked lately. While it is true that several decades
> ago it was hard to get such information, for at least the last decade
> manufacturers have been characterizing their synchronizer latches and
> publishing the results -- especially for their "metastability-hardened"
> designs.
But note that these will be "worst case" figures for the normal operation
of the part. I.e. they define a specification that the part is guaranteed
to exceed; no-one could have any cause for complaint to the manufacturer
if the part actually has *less* metastability than specified. Therefore,
these figures are effectively useless if what you want to do is guarantee
metastable operation.
> +---------------
> | the characterization of particular parts from particular lots from
> | particular manufacturers, who could change that operation at any time.
> +---------------
>
> That's true, but now that the problem is "out in the open" (where it
> wasn't at one time -- manufacturers didn't want to admit that true
> randomness existed!), they keep that info as up-to-date as any of
> the rest of the specs.
See above; if the metastability characteristics of a part "improve" for
normal operation (i.e. get worse from the point of view of someone trying
to use those characteristics in an RNG), it will still conform to the old
spec. That is, manufacturers will see this as a compatible change.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOf92tDkCAxeYt5gVAQFEVgf+PUUoeE5ssuDThL+wzFU3nGqOIONC8O43
YFjGP4i0XtW44v1EQZOgAciWMNnyyo1jd1yc8tdg1D6moHur+meaQq1len8gJDKE
UocQ0q4tGwJw8ZyJPPOMGDI3wOSG8pjQl23U97RZa/SWhs/rCFqgtRzPvzVUm44v
BSTPiHnEH6dE9tmUcva9Ug6FRYyG3rLzpED/KjuNU1OB0fyt8VmLcmuhXnNVcJLy
4kcjbVw0P1Hh+XJVwOMkwVoXqy5QkJW2ew10WNwpTVdOjGr68gSnUPn1ZUu5ozhO
Xp0hVfmwlUw2HZBPBTJbRNWRsgVDAbrvhD6FgZUclHaUByKBXKAa8w==
=W/+8
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 01 Nov 2000 02:41:52 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: XOR based key exchange protocol - flawed?
=====BEGIN PGP SIGNED MESSAGE=====
Mike Connell wrote:
> Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key Pi.
> Xa, Xb are random blocks of data of the same size as the public keys.
>
> 1. a -> b : Pa
> 2. a <- a : Pb
^ I assume this should be b
> 3. a -> b : (Xa)Pb
The number of passes could be reduced to 3 by eliminating message 1
and making this "Pa, {Xa}Pb". (A can still go first by swapping A and B.)
> 4. a <- b : (Xb)Pa
In the other responses to this thread, there seems to be some confusion
because the original description did not say whether public keys were
certified or known before the protocol starts. There are three cases:
1. If the public keys are certified, then messages 1 and 2 should be
explicitly sending certificates, not unsigned public keys.
2. If the public keys are not certified, but they are known to be correct
for some other reason (for example because key fingerprints, i.e.
hashes, have been exchanged over an authentic channel), then it is
redundant to send them in the protocol. It would be more efficient
and clearer to send the fingerprints instead in messages 1 and 2
(since a mapping from a fingerprint to a public key is assumed to be
known).
3. If the public keys are not certified or otherwise known to be correct,
then there is obviously a MITM attack.
Also note that the protocol does not provide forward secrecy, or explicit
key confirmation. IMHO this makes it a bad choice for new applications
even in cases 1 and 2.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOf+BBzkCAxeYt5gVAQHbJgf+Lrt2FPZbZsbChnE0Znoh/RWZ7FbwqmAs
+oNTKf3MZaxvjoDi5/QN4pk7awwLv75cssrk5bE3zme3XE8KKOhzfesHX56nhGiP
zoaxpyHyB4+GkUvU2150s+OAeATBUQIj1cfpmfJ1ohGsNUSSSwHDCcz9c6Z8rkA1
LrkwAVyv/M8TkCbLJ8Du7O8w9cJISIOCo5rEGoSVQ1WnZDhnboeuxx1N9rAhRM1T
iTEF9mQfWzc4ioa8gjjkE844jf5tpBhl/SRAbD6qQnb6PPAn0n7UrUXQJkp0Py69
NW05GbcY5r8iAYfGWuy0BB8g+jAIEpIZW1sRZ3dDY07Nkn06M89zrw==
=utVD
=====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
******************************
