Cryptography-Digest Digest #8, Volume #13 Thu, 26 Oct 00 17:13:00 EDT
Contents:
Re: How do I detect invalid passwords? ([EMAIL PROTECTED])
Re: My comments on AES ([EMAIL PROTECTED])
End to end encryption in GSM (Jouni Hiltunen)
Re: Xor values?? ([EMAIL PROTECTED])
Re: My comments on AES ([EMAIL PROTECTED])
Re: Collision domain in crypt()? ([EMAIL PROTECTED])
Re: Q: Computations in a Galois Field (Tom St Denis)
Re: Rijndael and PGP (Tom St Denis)
Re: How to post absolutely anything on the Internet anonymously (zapzing)
Re: Hardware RNGs (zapzing)
Re: Visual Basic (Ichinin)
Re: Hardware RNGs (David Schwartz)
Re: hardware vs. software vs. crypto accelerators ("Simon")
Re: Rijndael and PGP ("Michael Young")
Re: End to end encryption in GSM ("www.cellular-news.com")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How do I detect invalid passwords?
Date: Thu, 26 Oct 2000 17:58:46 GMT
As usual the standard disclaimers apply.
My first suggestion is this. Take a look at the Counterpane site, they
have information on password stretching that is compute intensive to
generate breaks. That's suggestion one, they have a large quantity of
information on it, and it is quite useful.
Suggestion 2. Make use of a newer more advanced password verifier.
There are many examples, from SRP, to EKE, SPEKE, etc, etc, etc. Use
these to verify the user, some offer very strong disjointedness between
the user password and the data stored on the server. Once the user has
enetered the correct password (as verified above), have the client send
across the hash of the user's password, use the hash to decrypt the
data. The hole in the logic is that the user must trust the server
during the decryption and must trust the server to correctly discard
the password hash when done. YMMV.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My comments on AES
Date: Thu, 26 Oct 2000 17:57:40 GMT
My understanding of an "attack" is defined as anything that forces
cracking runtime to be:
(keyspace-x) even if x=1.
No?
Albert
In article <[EMAIL PROTECTED]>,
Bruce Schneier <[EMAIL PROTECTED]> wrote:
> On Mon, 23 Oct 2000 22:19:18 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >
> >
> >James Felling wrote:
> >>
> >> An accademic attack is ANY attack that improves upon brute force.
If you can
> >> eliminate even a single key from the pool of potential candidates
via
> >> mathematical means it is a valid accademic attack. Heck if you can
assign an
> >> ordering of likelyhood to potential keys that is an attack. Any
method that is
> >> more efficient than straight brute force is an attack.
> >
> >For me that has the flavour of department stores of
> >having $99.99 instead of $100.00 counting as a discount.
>
> Indeed. It is an "academic discount," but not a discount that has any
> practical meaning. Sort of like the difference between an academic
> break of a cipher and a break that actually makes a difference in
> practice.
>
> Bruce
> **********************************************************************
> Bruce Schneier, Counterpane Internet Security, Inc. Tel: 408-556-2401
> 3031 Tisch Way, Suite 100PE, San Jose, CA 95128 Fax: 408-556-0889
> Free crypto newsletter. See: http://www.counterpane.com
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jouni Hiltunen <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt,alt.comp.opensource,alt.cellular.gsm
Subject: End to end encryption in GSM
Date: Thu, 26 Oct 2000 21:11:32 +0300
Greetings, first apologies in cross posting this to
hell and back, but I'm really interested in
extending privacy to cellular communications.
Here is the problem, present GSM system offers you
an illusion of privacy, communications are
supposedly secured by encryption. However, depending
on the operator and country you might have weak or
no encryption and no way to verify how your
communications are secured. Also encryption only
happens over the air interface i.e. between phone
and base station from there on all communications
are plain. To make matters worse, standards require
manufacturers to design legal interception gateways
into the switches.
What I have in mind is program which you could
download into your phone which allows Diffie/Hellman
key exchange and encryption of the following call to
make sure your private conversations remain private.
Anybody interested in developing a program to do
that? I sure as hell cannot do it myself,
Anyone interested in e-mailing me, please use the
public key below. Post the follow-ups to sci.crypt
Jouni Hiltunen
=====BEGIN PGP PUBLIC KEY BLOCK=====
Version: PGPfreeware 6.5.3 for non-commercial use
<http://www.pgp.com>
mQGiBDj8X6oRBADfW0QUWoXeQPV5Cys3xKXK4obFDX9NrR2p/1G6q9w8uC7AWh1z
IFVL6kvdpsmpDLh9COXYUiAjti9T9pWCBLj8ja/XrYIF9bmsi0Vhf7szDYfuCU1N
Ar44FcEAZv6+ifvNhb82TAzYwhX7cnBUVEm9Ql3BA8rsGNxtbl7HcUJnuQCg/zrC
Ujw9BIg+W/IdCoqmZ3F99J8EALuRnbf8hi2+A9MMTUEEf5JppLzBIcE5W4PSYVN9
dLXYpHwrOsn7HcaMtL53B5oCbbzYJX3fLvU9NZGEb9LHhhkFr/Q8B1jlhD00gapo
hAUQYB9T8tDz+/LBxnRwxnZyBrNjtpo9rFmBRI0ulaKT2ILMNnFNSoiL7CHL2fw5
NBw2A/9EkQnnLGCAGxP2DCfZVrbQiulJKA/v+FKIV9FlLy+UuINMWDebueLSSqbO
Hz1qe/PhfmnPufQttfAFuiwG6x7F2DAVyTncx2GzXDAMwMMq3tf6XjjTXGgWqoby
evV2xWIKEfJhMjfvGPRJu1gZVVtqGLhl1JEPK5bquyMXrft16bQrSm91bmkgSGls
dHVuZW4gPGpvdW5pLmhpbHR1bmVuQGtvbHVtYnVzLmZpPokATgQQEQIADgUCOPxf
qgQLAwIBAhkBAAoJEFHhnQ8I1H7Z4JYAoMjdiJ9LupLakXMWRkorpXt0lkS2AJ9y
xjEJqXfdY87AkiNWoK9msTlkzLkCDQQ4/F+rEAgA9kJXtwh/CBdyorrWqULzBej5
UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1
WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01ue
jaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJ
I8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaG
xAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuquiXsNV6TILOwAC
Agf+Mi5yC47v4wqthNU6FAHcrVd2SMrhDlPDNtoR6m5yry3fO95FxBrXV4OnVVSe
hb6OwysvG4yltg26wzCJHwaw1W2zVm4x3FWGJ5rLqvHS3T9z2lKvg6+Emvwk5mYs
mTYPiQNN00mZpnxyjQ5byX+GOrUG04zaReuHe0Sy9OyUG9Gsi9ISD5Xw+Ww+8afe
hSsp+xnojyD9e2GVwL1EHjYiS4U5MkQRJOYbrAF32g+4Ssydl/tT38bxU/dyp967
VV6tD+RTFdRtgQeYzbEqOhIcC8rKE2CBO27icpEuLbtedf4wsjtp9qING8nM8tX1
zIwvw3PT1n2h0//PPUvW5ATbHIkARgQYEQIABgUCOPxfqwAKCRBR4Z0PCNR+2YBi
AKCvRJ7IVzYk14zbS8EwdJhjN8DEXwCg1X35+5PCRzXFqqvih8bgv2t1WGg=
=isQf
=====END PGP PUBLIC KEY BLOCK=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Xor values??
Date: Thu, 26 Oct 2000 18:05:52 GMT
XOR is really quite simple, once someone explains it.
I assume you know how to convert to binary numbers
It works like this.
12 XOR 6
First split the numbers into single bits
1100 XOR 0110
Next arrange the numbers like so
1100
0110
Look up the value of each column in
in in out
1 1 0
1 0 1
0 1 1
0 0 0
Fill in the bottom column
1010
Convert back to normal numbering
10
Alternately, once you get to the binary representation if the the
column has one 1, and one 0, the value is 1, otherwise it's 0.
There are a great many different ways to view it, this is the one I've
found the easiest to explain to people.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My comments on AES
Date: Thu, 26 Oct 2000 18:10:28 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
>It is not inconceivable that all possible ciphers have some kind of
>academic break. I'd be intensely interested in a proof (or even a
>sketch of a proof) that it is even possible for a non-OTP cipher to be
>certified against such breaks.
Academic breaks are a special case. If it were possible to certify a
cipher against academic breaks then it would also be possible to
certify it against any break at all.
> > Now, all 5 finalists have proven to be
> > flawless in this sense
>
>This assertion is false. There is no "proveness" about it. There is
>only lack of known weakness, which is a comment upon our ignorance,
>not upon the strength of the ciphers.
I see your point, but my assertion was made within the context of
NIST's selection process. The word "proven" in English is often used
not in the sense of mathematical proof but rather in the sense of "have
been shown in praxis". I remember some time back I criticized a post of
Bruce Schneier where he stated something like "DES has proven to be
secure", and now it is I who falls in the same linguistic trap.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Collision domain in crypt()?
Date: Thu, 26 Oct 2000 18:17:07 GMT
> What's the collision domain in a standard (Solaris) crypt() function?
IIRC it's 64-bit, but I might be remembering wrong, or they may have
changed it since then.
> I'm in need of a simple hash function for ~4 million items, with a
digest of
> approx 10-14 chars; MD5 et al at 32 characters is simply overkill.
Am I
> in the right ballpark?
Just take MD5 and chop off what you don't need, it'll actually be
faster than crypt().
BTW, I noted the e-mail address. I'm still gonna let you slide with
decent security.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Thu, 26 Oct 2000 18:29:12 GMT
In article <8t9dui$pmb$[EMAIL PROTECTED]>,
"kihdip" <[EMAIL PROTECTED]> wrote:
> Twofish and Rijndael (among others) use computations in a Galois
Field.
>
> Can any of you explain to me why the Galois Field is usefull.
(Advantages)
> Is it because of the modulus, so you'll never get more than 8 bits ??
> Or because it eases decryptation ??
Well for starters all galois field operations in GF(2)^n involve single
bits (thus shifting/xors/ands, etc...) which makes them efficient on a
a plethora of platforms.
Second a multiply of two n-bit elements only needs an n-bit temporary
variable whereas in GF(p) you need a log2(p^2) bit temp variable.
Third inversion (and cubing) are highly usefull operations in GF(2)^n
fields since they have low xor/linear biases.
> Rijndael uses 11B and Twofish uses 169 - how do one choose the
irreductable
> polynomia ?? Are some better than others ??
No polynomial is "better" then another. There are about 25 polynomials
of nine bits (8-bit fields).
I suggest you read the Rijndael paper about manipulating the elements.
If you have any specific questions please ask.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Rijndael and PGP
Date: Thu, 26 Oct 2000 18:30:21 GMT
In article <8t9qio$rbc$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <8t4jjk$hq9$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <bsgJ5.161$[EMAIL PROTECTED]>,
> > "George Gordon" <[EMAIL PROTECTED]> wrote:
> > > Rijndael and PGP. What's the word on this?
> > >
> >
> > You have succesfully named two buzzwords. Your homework is to study
> > why your question is stupid.
> >
> > Honest, the ciphers in PGP (IDEA, CAST, 3DES) are secure enough,
> adding
> > Rijndael will ****NOT**** make PGP any better or usefull then it
> > already is.
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
> Indeed, Rijndeal is faster than Twofish but not as secure. It appears
> than Zimmerman likes his ultra-secure ciphers (hence IDEA, CAST and 3-
> DES). So i would agree with Tom's reasoning, and say its unlikely that
> Rijndeal will be included in PGP.
Hey hey, I never justified Twofish being in there. By your logic
Serpent should have been added.
I just said adding Rijndael will not make it any better.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.freespeech
Subject: Re: How to post absolutely anything on the Internet anonymously
Date: Thu, 26 Oct 2000 19:23:00 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> Come on, try it. Also, be sure to tell your immediate family and
> other relatives.
>
> Test your position in logic.
>
> After all, you said it made no difference.
Not at all. I said it was an invalid argument.
There could certainly be very serious
consequences to any individual who speaks
out against accepted wisdom. This does not,
however, mean that the "accepted wisdom" is
true.
In fact, that's one of the reasons that I
like the idea of being able to speak
anonymously.
> I says it does.
>
--
Void where prohibited by law.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Thu, 26 Oct 2000 19:35:07 GMT
In article <8t96a6$9d2$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > >
> > > In article <[EMAIL PROTECTED]>,
> > > Cameron <[EMAIL PROTECTED]> wrote:
> > > > Why don't you just use soundcard input?
> > > > pipe it into a file. It should be pretty darned random.
> > >
> > > Um not really.
> > Then use it (and the previous hash) as input to sha to get
> > 160 bit of random data. Repead as needed.
>
> The problem is that virtually of the lsb's on my comp are zeroes, with
> a few ones... In fact last time I counted the ratio was about 7 to 1.
> This means you need to gather about 100,000 bits before you can safely
> have about 160 bits (using SHA-1). However, the problem gets
> worse...you must sample very slowly, otherwise the samples are
> correlated... Thus sample at about 8khz. At 8khz it will take 12.5
> seconds to gather enough inputs....
Actually it seems to me that if 1 out every
8 bits is a 1 then out of 8 bits you should
have about 3 bits of randomness (such as to
describe the position of the "1" in the 8
bit group).
> Your best bet is to use a free-running timer and/or some other sources
> (keyboard input+timing)...
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
Void where prohibited by law.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Visual Basic
Date: Thu, 26 Oct 2000 09:54:20 +0200
mdc wrote:
> Nope, at least up until VB5 the integer type is signed only.
> That may have changed in VB6, but I don't believe so. This
> means you can't store an unsigned 16 bits in an integer type.
> You could use long or variant types, but many of the functions
> like mod require integer arguments. Hence my comment about
> overloading those functions.
>
> If VB6 actually does allow unsigned integers then this would
> remove a huge performance block on using VB for algorithms
> like Blowfish, etc. I'd be interested if this were true, but I
> haven't bothered to look that hard at VB6.
>
> mdc
Well, feeding data into a variable using an alternative way is usually
the only way...
Dim X As Double
X = Val("1221238761724812")
Debug.Print X
X = Int(X / 65536)
Debug.Print X
X = Int(X * 65536)
Debug.Print X
Regards,
Ichinin
.SE
(VB _&_ C++ coder)
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Thu, 26 Oct 2000 13:02:38 -0700
Tom St Denis wrote:
> The problem is that virtually of the lsb's on my comp are zeroes, with
> a few ones... In fact last time I counted the ratio was about 7 to 1.
> This means you need to gather about 100,000 bits before you can safely
> have about 160 bits (using SHA-1). However, the problem gets
> worse...you must sample very slowly, otherwise the samples are
> correlated... Thus sample at about 8khz. At 8khz it will take 12.5
> seconds to gather enough inputs....
If you are correct that one in every eight bits is a one and they are
otherwise uncorrelated, you should need no more than 512 bits of input
to get 160 bits of entropy. Two hundred milliseconds worth of data
should be perfect.
DS
------------------------------
From: "Simon" <[EMAIL PROTECTED]>
Subject: Re: hardware vs. software vs. crypto accelerators
Date: Thu, 26 Oct 2000 21:12:02 +0100
I need to define an architecture that lists what crypto services are
required, and how they should be delivered. The requirements range from
simple secure email, ssl, right through to application specific encryption,
and as the company are looking to deliver financial products, there is a
requirement for payments to be macced, and protected in transit.
So essentially there is a wide range of services required, and I want to put
forward a paper that compares software toolkits against on host accelerators
against network crypto appliances.
"Simon" <[EMAIL PROTECTED]> wrote in message
news:8t7023$sde$[EMAIL PROTECTED]...
> Could anybody point me in the direction of a good resource comparing and
> contrasting the various approaches to delivering cryptographic services
for
> enterprise customers?
>
> Replies to [EMAIL PROTECTED] would be appreciated.
>
>
------------------------------
From: "Michael Young" <[EMAIL PROTECTED]>
Subject: Re: Rijndael and PGP
Date: Thu, 26 Oct 2000 16:08:50 -0400
Unlike Tom, the authors of the OpenPGP spec (RFC2440) did see value in
offering the AES winner as an option (even before it was announced), and
put in placeholders for it.
I'm in no position to say when, but I expect the major players (PGP/NAI,
GnuPG)
to follow the OpenPGP spec. But maybe Tom has more pull with them than I
think.
I guess I need to do more homework.
------------------------------
From: "www.cellular-news.com" <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt,alt.comp.opensource,alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Thu, 26 Oct 2000 21:40:37 +0100
You cannot "download" a software patch of that nature into GSM phones - one
of the reason why viruses don't affect mobiles.
Anyhow my conversations are not interesting enough - I think I would
probably get charged with murder for boring the SIS operative listening to
me to death.
--
For the latest news and coverage maps for the GSM industry........
http://www.cellular-news.com
"Jouni Hiltunen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Greetings, first apologies in cross posting this to
> hell and back, but I'm really interested in
> extending privacy to cellular communications.
>
> Here is the problem, present GSM system offers you
> an illusion of privacy, communications are
> supposedly secured by encryption. However, depending
> on the operator and country you might have weak or
> no encryption and no way to verify how your
> communications are secured. Also encryption only
> happens over the air interface i.e. between phone
> and base station from there on all communications
> are plain. To make matters worse, standards require
> manufacturers to design legal interception gateways
> into the switches.
>
> What I have in mind is program which you could
> download into your phone which allows Diffie/Hellman
> key exchange and encryption of the following call to
> make sure your private conversations remain private.
>
> Anybody interested in developing a program to do
> that? I sure as hell cannot do it myself,
>
> Anyone interested in e-mailing me, please use the
> public key below. Post the follow-ups to sci.crypt
>
> Jouni Hiltunen
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: PGPfreeware 6.5.3 for non-commercial use
> <http://www.pgp.com>
>
> mQGiBDj8X6oRBADfW0QUWoXeQPV5Cys3xKXK4obFDX9NrR2p/1G6q9w8uC7AWh1z
>
> IFVL6kvdpsmpDLh9COXYUiAjti9T9pWCBLj8ja/XrYIF9bmsi0Vhf7szDYfuCU1N
>
> Ar44FcEAZv6+ifvNhb82TAzYwhX7cnBUVEm9Ql3BA8rsGNxtbl7HcUJnuQCg/zrC
>
> Ujw9BIg+W/IdCoqmZ3F99J8EALuRnbf8hi2+A9MMTUEEf5JppLzBIcE5W4PSYVN9
>
> dLXYpHwrOsn7HcaMtL53B5oCbbzYJX3fLvU9NZGEb9LHhhkFr/Q8B1jlhD00gapo
>
> hAUQYB9T8tDz+/LBxnRwxnZyBrNjtpo9rFmBRI0ulaKT2ILMNnFNSoiL7CHL2fw5
>
> NBw2A/9EkQnnLGCAGxP2DCfZVrbQiulJKA/v+FKIV9FlLy+UuINMWDebueLSSqbO
>
> Hz1qe/PhfmnPufQttfAFuiwG6x7F2DAVyTncx2GzXDAMwMMq3tf6XjjTXGgWqoby
>
> evV2xWIKEfJhMjfvGPRJu1gZVVtqGLhl1JEPK5bquyMXrft16bQrSm91bmkgSGls
>
> dHVuZW4gPGpvdW5pLmhpbHR1bmVuQGtvbHVtYnVzLmZpPokATgQQEQIADgUCOPxf
>
> qgQLAwIBAhkBAAoJEFHhnQ8I1H7Z4JYAoMjdiJ9LupLakXMWRkorpXt0lkS2AJ9y
>
> xjEJqXfdY87AkiNWoK9msTlkzLkCDQQ4/F+rEAgA9kJXtwh/CBdyorrWqULzBej5
>
> UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1
>
> WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01ue
>
> jaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJ
>
> I8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaG
>
> xAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuquiXsNV6TILOwAC
>
> Agf+Mi5yC47v4wqthNU6FAHcrVd2SMrhDlPDNtoR6m5yry3fO95FxBrXV4OnVVSe
>
> hb6OwysvG4yltg26wzCJHwaw1W2zVm4x3FWGJ5rLqvHS3T9z2lKvg6+Emvwk5mYs
>
> mTYPiQNN00mZpnxyjQ5byX+GOrUG04zaReuHe0Sy9OyUG9Gsi9ISD5Xw+Ww+8afe
>
> hSsp+xnojyD9e2GVwL1EHjYiS4U5MkQRJOYbrAF32g+4Ssydl/tT38bxU/dyp967
>
> VV6tD+RTFdRtgQeYzbEqOhIcC8rKE2CBO27icpEuLbtedf4wsjtp9qING8nM8tX1
>
> zIwvw3PT1n2h0//PPUvW5ATbHIkARgQYEQIABgUCOPxfqwAKCRBR4Z0PCNR+2YBi
>
> AKCvRJ7IVzYk14zbS8EwdJhjN8DEXwCg1X35+5PCRzXFqqvih8bgv2t1WGg=
>
> =isQf
> -----END PGP PUBLIC KEY BLOCK-----
>
------------------------------
** 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
******************************
