Cryptography-Digest Digest #778, Volume #13 Fri, 2 Mar 01 10:13:01 EST
Contents:
PKI and Non-repudiation practicalities (Mark Currie)
Re: encryption and information theory (William Hugh Murray)
Re: How good is the KeeLoq algorithm? (Mark Currie)
Re: Safe to use DSS key for DH? (DJohn37050)
Re: confused:Diffie-Hellman is key agreement, how about RSA? Is RSA both algorithm
and keyagreement? (DJohn37050)
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
repeating codes ("Eric Mosley")
Re: RC4 like stream cipher ("Tom St Denis")
Good Security Products?? ("Matthias Bauer")
Re: RC4 like stream cipher ("Henrick Hellstr�m")
Re: super-stong crypto, straw man phase 2 (William Hugh Murray)
Re: How good is the KeeLoq algorithm? (Frank Gerlach)
Re: "RSA vs. One-time-pad" or "the perfect enryption" (William Hugh Murray)
Re: Urgent DES Cipher source code !!!!! ("MVJuhl")
Re: => FBI easily cracks encryption ...? (William Hugh Murray)
Re: Good Security Products?? (Frank Gerlach)
Re: How good is the KeeLoq algorithm? (S�ren A.M�ller)
Re: repeating codes (Frank Gerlach)
Text of Applied Cryptography ("Ryan M. McConahy")
Re: Good Security Products?? ("Matthias Bauer")
Re: Text of Applied Cryptography ("Erick Perez")
----------------------------------------------------------------------------
Subject: PKI and Non-repudiation practicalities
From: [EMAIL PROTECTED] (Mark Currie)
Date: 02 Mar 2001 12:23:40 GMT
Hi,
Non-repudiation is often used as a selling point for PKI but this can be
misleading. Non-repudiation requires additional infrastructure such as
databases for storing each signed message together with its corresponding
signature. In high-throughput applications the amount of storage needed can be
very large indeed. There are many applications of public key cryptography (i.e.
communications security) where Non-repudiation is impractical because of the
storage requirement. Non-repudiation would also require independent validation
services that are capable of verifying the message originator given a message,
signature & certificate. These services would have to demonstrate a high level
of trustworthiness since the output is likely to be a simple Yes/No. The full
implications of supporting Non-repudiation may not be that clear to PKI
customers and their application developers. The message that often comes across
is that PKI / PK technology gives you Non-repudiation. It does not. It seems to
me that there needs to be more information around the practical implementation
of Non-repudiation.
It is possible that these issues are now being addressed by PKI vendors. Does
anyone know of any literature that covers the practical issues around
Non-repudiation ?
Mark
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: encryption and information theory
Date: Fri, 02 Mar 2001 12:37:06 GMT
Mxsmanic wrote:
> "Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > Consider symettric encryption. Is there information
> > added to the message during encryption which the attacker
> > does not know?
>
> No.
>
> > YES, the secret key is added, and the attacker does not
> > know the secret key.
>
> The secret key is not added to the message. Nothing is added to the
> message. Parts of the message are transposed, and parts are
> substituted, but the overall information content remains the same.
I agree. What has been added is a new code and code book but that
information is in the alogorithm and the key, not in the cryptogram.
Now in order to understand the message one must have at least two code
books, the public one(s) in which the original message was encoded and
the secret one.
------------------------------
Subject: Re: How good is the KeeLoq algorithm?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 02 Mar 2001 12:45:49 GMT
Many remote controlled security gates and vehicle alarms today still make use
of an un-changing transmitted code. The danger here is that a determined thief
gets hold of a device that can record the transmission and later re-transmit
the code to gain access. Keeloq was designed to provide significant improvement
over this. You now need to involve a highly skilled cryptographer who may/may
not be able to crack the cipher.
In article <1103_983533150@3s-sam-pc>, [EMAIL PROTECTED] says in part...
>
>Isn't it easier to move the car to someplace else and remove the car alarm
etc.?
>
I think that this is exactly how you should view the thing.
Mark
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 02 Mar 2001 12:58:59 GMT
Subject: Re: Safe to use DSS key for DH?
Actually, using a too large subgroup introduces ineffiencies. It is best to be
approx. balanced ;=)
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 02 Mar 2001 13:01:09 GMT
Subject: Re: confused:Diffie-Hellman is key agreement, how about RSA? Is RSA both
algorithm and keyagreement?
I also agree with Bill Murray that key management is much bigger than just key
establishment. Let's use the correct terms to avoid confusion.
Don Johnson
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 02 Mar 2001 13:14:45 GMT
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:xtLn6.375$[EMAIL PROTECTED]...
> Very true. BTW it's 'Galois'.
Sorry. I knew it started with Ga-something, but I was too lazy to look
it up.
> For machines storing classified information,
> the NSA secure facility rules take over - this
> hardware / software is likely to be quite
> different from standard pc's.
I question why the FBI has a need to handle information at these levels
in the first place, at least on any regular basis. It sounds like there
might be a lot of overclassification going on, which only weakens the
security of classifications as a whole.
------------------------------
From: "Eric Mosley" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: repeating codes
Date: Fri, 02 Mar 2001 13:27:49 GMT
Hi,
I generate random codes like the following:
H5R6-8UPG
where each digit is 0-9, A-Z
Now, if I start to generate these random codes today how many can I generate
before there is a probability that I will hit one of the previously
generated codes? And how do you work that out anyway?
Any info would be great,
Eric
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RC4 like stream cipher
Date: Fri, 02 Mar 2001 13:32:19 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:97nkv1$r7j$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:mJBn6.349$[EMAIL PROTECTED]...
> >
> > "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> > news:97mo69$2c3$[EMAIL PROTECTED]...
> > > I found a crack with a 90% success rate and less than 7% false hits
> given
> > > 2048 bytes of known plain text. The major problem is step 4. Your
> proposed
> > > modification of step 3 did not have any impact whatsoever on the
success
> > > rate of this attack. I simply exploited the weakness intruduced by
step
> 4
> > > you outlined yourself and wrapped it in a brute force attack on the
> 2-byte
> > > state.
> >
> > Hmm if you wrote your attack in C I could try this myself but...
> >
> > Try changing to
> >
> > 1. t1 <= S[sy]
> > 2. swap S[sy] with S[sx]
> > 3. sy <= (sy + sx + 1) mod 256
> > 4. sx <= t1
> > 5. return t1
>
> That's just as bad. If the attacker sees the digraph (a, b) on the
output,
> he then knows that, after that digraph has been output, S[a]==b. And, if
> the attacker assumes sy at one point (that is, he cycles through all 256
> possible sy values), he can track the value of sy at all times, since he
> knows sx at all times and sx is the only thing that modifies sy. Ok, it's
> slightly better in that the attacker has to try 256 values of sy, rather
> than be given it.
>
> So, for every output, a byte of the array is revealed. And, once the
> attacker knows it, he can keep track of it forever. So, after a thousand
or
> so outputs, the attacker knows the vast majority of the array state...
Ah, but you're slightly wrong. You are given S[sy] and are never given sy.
So you know there is a byte "t1" in the array but you don't know where. And
you know in the next byte that the positions (?, sx) are used in the swaps.
You never know what "sy" is though directly.
Tom
------------------------------
From: "Matthias Bauer" <[EMAIL PROTECTED]>
Subject: Good Security Products??
Date: Fri, 2 Mar 2001 14:49:07 +0100
Hi there,
I want to secure a client (pure Java) / server network (C++) for a document
management system. I have already a complete implementation of the network
API, but without any security components and I'm not very familiar with any
products on the market.
Now I'd like to have a list of serveral providers
(commercial/none-commercial) of products for security components in a
client/server environment.
Thanks,
Matthias.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: RC4 like stream cipher
Date: Fri, 2 Mar 2001 14:54:48 +0100
A quick response is that Scott's modification would be broken at least as
fast as brute force on a 844-bit key (equivalent to the number
256*254*252*250*...*2, representing the amount of assumption you would have
to make if you always had bad luck and never encountered any inconsistency
until you had chosen the entire SBox. Such bad luck is logically impossible
of course, so there are better approximations of the upper bound.).
For each single byte hypotethis (the value of S[i]), you may deduce one
other byte of key data (the value of S[j]) from evidence (S[j] = output -
S[i]). Keep track of your assumptions, and once you've encountered an
inconsistency (the values of S[i] and S[j] have both already been assumed
and their sum differs from evidence), roll back your attack to the output
position where you last made an assumption that entailed the inconsistency.
Using the corresponding method, you could break RC4 at least as fast as
brute force on an 1125-bit key (equivalent to the number
(256*255)*(253*252)*(250*249)*...), since for each two-byte hypothesis (the
values of S[i] and S[j]) you may deduce another byte from evidence (the
value of S[S[i] + S[j]]).
Another interesting difference between Scott's cipher and RC4 is that RC4
actually seems to have a smaller unicity distance, i.e. you might expect to
need less output from RC4 to determine the key by brute force!
I'll see if I'll come up with something practical.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Scott Fluhrer" <[EMAIL PROTECTED]> skrev i meddelandet
news:97nkv1$r7j$[EMAIL PROTECTED]...
> One of the things I've been playing around with is the RC4 variant:
>
> 1. i := i + 1
> 2. j := j + S[i]
> 3. swap S[i], S[j]
> 4. output S[i] + S[j]
>
> (all additions mod 256).
>
> This is regular RC4, except the output has one array dereference removed.
> One would expect that this should be relatively breakable, but nothing I
> tried has worked so far. Henrick, do you have any clues?
>
> --
> poncho
>
>
>
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: super-stong crypto, straw man phase 2
Date: Fri, 02 Mar 2001 14:01:44 GMT
"Douglas A. Gwyn" wrote:
> William Hugh Murray wrote:
> > "Douglas A. Gwyn" wrote:
> > > William Hugh Murray wrote:
> > > > In any case, most of us do not worry about keeping secrets from
> > > > nation states for a long time.
> > > Well, you should!
> > I admit that I do like to confound authority.
>
> Another point is that "super strong crypto" ought to mean that
> *nobody* can come up with a practical attack;.....
I will buy your hypothesis.....
> .......if you allow that
> some "nation-state" can successfully attack a given system, then
> that demonstrates that that system was not "super strong".
...but not your conclusion.
<Soapbox_mode_on>
For the sake of life and limb, and for reasons of which you are well
aware, I must always "allow" that a nation state can break the _system_.
There is a difference between strong crypto and strong crypto systems.
While a cryptogram may be perfect, a system cannot be. While a system
can be resistant, it can never be proof. While it may be resistant to
"practical" attacks, it can never be resistant to all attacks. Anything
built by man can be broken by man. "Practical" is a relative word. I
describe security as practical when the cost of attack exceeds the value
of success (for forseeable circumstances). The problem with practical is
that those numbers are not knowable.
The method of encryption has never been the weak link in the system.
Nation states use duplicity, coercion, and force. While the cryptogram
may well be resistant to these, the system never can be (at least until
the data is irretrievably lost.)
Though the state is forever misquoting him for its own purposes, Shannon
never said that the OTP yields perfect security. He said that it yielded
provably perfect cryptograms. That is a very different thing. One may
assert to the contrary all one likes but those are the facts, not to say
the facts of life. While they are often forgotten by cryptographers, the
rest of us forget the difference between strong cryptography and strong
security at our peril. The former is may be necessary to but is not
sufficient for the latter.
While I cannot prove it, I assert that modern cryptography already
exceeds the strength of the next strongest component in the _system_ by
orders of magnitude hardly seen in astronomy. By inspection, even with
block ciphers, as I change the key more frequently, the length of the
data encrypted under any single key approaches the length of the key
(sound familiar?), the cost of attack goes up with the number of new
keys, and the value of success for finding a particular key goes down.
The ratio of these numbers approaches infinity. That is called close
enough for government work.
Now, I am not opposed to cryptography. I am not trying to dismiss it. I
have had, not to say used up, many friends among cryptographers. I use
their calculations and their insights all the time. I do not object if
they continue to chase their Holy Grail of ever stronger ciphers, not to
say provably secure cryptograms within "practical" systems. After all,
history is replete with advances in cryptanalysis. If there are any out
there who are chasing provably secure and practical systems, then I can
only say that I am sorry for them.
I am a security person. I must live in the real world, not the abstract
world of mathematical proofs. In that world, a marginal increase in the
security of cryptograms does not buy me enough to be worth the effort of
cryptographers. In that world, the cost of cryptanalysis has always been
high and it has never dropped suddenly. The cost of force has always
been cheapest just when one most needs protection. If one wants to be
really helpful, one should worry about the weak links in the system,
those vulnerable to force, not the one already most resistant to both
force and logic..
<Soapbox_mode_off>
I love this message. I think that it bears repeating from time to time.
I know that security people need it and it may be helpful to
cryptographers. Thanks for provoking me to give it once more.
Please keep up the good work and keep your sense of humor.
William Hugh Murray, CISSP
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: How good is the KeeLoq algorithm?
Date: Fri, 02 Mar 2001 15:13:03 +0100
"S=F8ren A.M=F8ller" wrote:
=
> There is an introduction to KeeLoq here:
> http://www.microchip.com/10/appnote/category/keeloq/91002/index.htm
Had a quick look at it. Still not convinced.
Also they state something like "32 bit key". This is not really strong.
The russians could easily set up a Linux-PC farm somewhere in
Wladiwostok (or whereever their ratsnest is) and go through those four
billion possibilities in five minutes. And yes, you can send something
to russia and get it back in five minutes.
This technology seems to stem from the bad old days of crypto regulation
and they wanted to avoid the need to get an export license.
> What you get is the decryption source code and a licence agreement (tha=
t you
> don't need to sign).
And the idea is to deny the russians access to the algorithm, or what ?
> =
> <snip>
> > Why can't they use a standard algorithm such as DES or RC4 ??
> =
> Probably because the algorithm output should be short (32 bits) and it =
is
> implemented in a low cost microcontroller with limited capabilities.
Anybody who is worth being called an engineer will implement RC4/ArcFour
in less than a day in Z80 assembler.
> It is inplemented with the use of single bit rotations, xor and a very =
small look-up
> table only.
Same with RC4, only that the (constantly changing) table is 256 bytes of
RAM.
> =
> > Sounds like the russian car mafia should have a look at that :-))
> They probably allready have :-)
> =
> Isn't it easier to move the car to someplace else and remove the car al=
arm etc.?
Isn't it much more convenient to wait at the disco with a laptop &
receiver, get the codes for all the BMW's and then open them
electronically ? No scratches, no trucks etc..
This could easily be less secure than the good old mechanical key !
<[EMAIL PROTECTED]>
Organisation: =
UNI-C
Newsgruppen: =
sci.crypt
Verweise: =
1 , 2
On Fri, 02 Mar 2001 10:54:02 +0100, Frank Gerlach =
<[EMAIL PROTECTED]> wrote:
<snip> =
>> Does there exist any analysis og the KeeLoq crypto algorithm?
(whoops, a typo - I meant 'of' not 'og'.)
>Never heard of it.
There is an introduction to KeeLoq here:
http://www.microchip.com/10/appnote/category/keeloq/91002/index.htm
> Secret algorithms are always a bad sign in cryptography.
Well it is not a total secret.
As I mentioned you can buy the decryption part without any problems.
What you get is the decryption source code and a licence agreement (that
you =
don't need to sign).
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Date: Fri, 02 Mar 2001 14:09:13 GMT
"Douglas A. Gwyn" wrote:
> Steve Meyer wrote:
> > >It will be interesting to see your argument. I know of no
> > >evidence that this was a factor. If you turn the question
> > >around and ask, why did workers for government cryptologic
> > >organizations get there first, an obvious answer would be:
> > >They had more experience, more support, and more at stake.
> > I do not think they did, i.e. only evidence seems to be popular
> > book (see my rump talk).
>
> Are we talking about the same thing -- the discovery of
> nonsecret encryption (aka public-key encryption)? If so,
> I assure you that there is considerable evidence that it
> was independently invented by Ellis, Cocks, and Williamson,
> well before the DH,RSA work.
Perhaps. When one fails, for whatever reason, to publish
contemporaneously, one often loses the credit. However, in this case,
far more significant than that they did not publish (the circumstances
more than account for that) is the fact that even if they had the idea,
it never made a difference. However credible the documents, there has
been no evidence put forth that the idea was ever implemented, much less
that it made a difference. The Diffie-Hellman work changed history and
Ellis, Cocks, and Williamson will be no more than a footnote.
------------------------------
From: "MVJuhl" <[EMAIL PROTECTED]>
Subject: Re: Urgent DES Cipher source code !!!!!
Date: Fri, 2 Mar 2001 15:17:15 +0100
What is wrong with you people ?!
All he wants is a little help, and the only one who understands his request
is Panu H�m�l�inen.
It actually IS possibly not being able to find what you are looking for when
using search engines. You might not have the knowledge about what you are
searching for in order to refine your search and find it.
Maybe you get tired of looking through search results and would like to ask
somebody instead. Would this not be the right place to ask ?
So many replies to a request so simple that one containing a simple link is
enough.
Latyr Jean-Luc FAYE writes:
>I apologies for botherring you with my request.
>I thought that we were in a friendly and helpful environement
YOU make him apologies for his question !!??!
And don't think it's because there is something wrong with HIM!
If you want to help, do so!
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 02 Mar 2001 14:14:20 GMT
Mxsmanic wrote:
> "groj" <[EMAIL PROTECTED]> wrote in message
> news:97n8l8$mk5$[EMAIL PROTECTED]...
>
> > One would presume that government computers at
> > that level would all be recorded as a matter of
> > course??
>
> I might presume that for an agency like the NSA, which has considerable
> experience in establishing and maintaining security. I would not
> presume that for the FBI, which has traditionally been more concerned
> with things like guns than with Gaulois fields.
>
> I suspect that FBI PCs are essentially identical to any other PCs.
And, as a matter of public record, until recently their messaging system
certainly was essentially like any other.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Good Security Products??
Date: Fri, 02 Mar 2001 15:15:47 +0100
check www.rsa.com or SSLeay (free!)
Matthias Bauer wrote:
>
> Hi there,
>
> I want to secure a client (pure Java) / server network (C++) for a document
> management system. I have already a complete implementation of the network
> API, but without any security components and I'm not very familiar with any
> products on the market.
>
> Now I'd like to have a list of serveral providers
> (commercial/none-commercial) of products for security components in a
> client/server environment.
>
> Thanks,
>
> Matthias.
------------------------------
From: S�ren A.M�ller <[EMAIL PROTECTED]>
Subject: Re: How good is the KeeLoq algorithm?
Date: Fri, 02 Mar 2001 14:30:49 GMT
On Fri, 02 Mar 2001 15:13:03 +0100, Frank Gerlach <[EMAIL PROTECTED]> wrote:
> Had a quick look at it. Still not convinced.
> Also they state something like "32 bit key". This is not really strong.
Actually 32 bit block, 64 bit key
The idea is that both transmitter and receiver contain a counter (16 bit in this
implementation).
This value of this counter is encrypted and sent every time the transmitter transmits.
The transmitter also transmits a serial number and button info.
The receiver checks if it knows the serial number. If it does it then decrypts the
encrypted counter
value and compares it to a stored counter value from the last received transmission.
If the new value
is less than 16 values ahead, the new value is stored and access is granted. If the
new value is more
than 16 values ahead, the receiver stores this value and waits for a new transmission
which must
have a counter value 1 ahead before granting access.
With a transmission rate of max. 10/sec and a 32 bit encrypted block the security is
actually pretty
high since you need two consecutive counter values (or one in the 16 value window) to
gain access.
--
S�ren A.M�ller
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: repeating codes
Date: Fri, 02 Mar 2001 15:29:10 +0100
If you have 8 letters, it will be (26+10)^8==100000026 possible codes.
So if you have a simple counter, you will generate an identical number
after about 100 Million numbers generated. If you use a pseudo-random
number generator, chances can differ widely, depending on the generator.
Also be aware of the fact that some(most ?) pseudo random number
generators will allow you to easily calculate number R(n) from R(n-1).
The rand() implementation of most C runtime systems is an example of
this.
>
> Hi,
>
> I generate random codes like the following:
> H5R6-8UPG
> where each digit is 0-9, A-Z
>
> Now, if I start to generate these random codes today how many can I generate
> before there is a probability that I will hit one of the previously
> generated codes? And how do you work that out anyway?
>
> Any info would be great,
>
> Eric
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Text of Applied Cryptography
Date: Wed, 28 Feb 2001 18:58:10 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Where can I find the text of Applied Cryptography in text or MSWord
format? I found it for Acrobat, but I'd wrather have it in something
smaller...
Thanks in advance,
Ryan M. McConahy
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: KeyID: 0xA167F326A5BE3536
Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
iQA/AwUBOpxAq6Fn8yalvjU2EQJVWwCgt8oeMazloBdTwzPuKxco2nDFl2sAoNZg
EFpPWF6abc90uJUFMoVjVlSU
=oCc+
=====END PGP SIGNATURE=====
------------------------------
From: "Matthias Bauer" <[EMAIL PROTECTED]>
Subject: Re: Good Security Products??
Date: Fri, 2 Mar 2001 15:49:10 +0100
Hi Frank,
Thank you, but am looking for more - I have to make a compairson table of
serveral providers......
------------------------------
From: "Erick Perez" <[EMAIL PROTECTED]>
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography
Date: Fri, 2 Mar 2001 10:01:44 -0500
Can you please let me now where to get the PDF you mention?
Thanks,
Erick.
Ryan M. McConahy <[EMAIL PROTECTED]> wrote in message
news:3a9faf9e$0$35010$[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Where can I find the text of Applied Cryptography in text or MSWord
> format? I found it for Acrobat, but I'd wrather have it in something
> smaller...
>
> Thanks in advance,
>
> Ryan M. McConahy
>
> -----BEGIN PGP SIGNATURE-----
> Version: 6.5.8ckt http://www.ipgpp.com/
> Comment: KeyID: 0xA167F326A5BE3536
> Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
>
> iQA/AwUBOpxAq6Fn8yalvjU2EQJVWwCgt8oeMazloBdTwzPuKxco2nDFl2sAoNZg
> EFpPWF6abc90uJUFMoVjVlSU
> =oCc+
> -----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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
