Cryptography-Digest Digest #766, Volume #9 Fri, 25 Jun 99 04:13:05 EDT
Contents:
Re: Description of the scottNNu algorithms..... (SCOTT19U.ZIP_GUY)
Re: Kryptos article ([EMAIL PROTECTED])
Re: VIC cipher now described on web site (UBCHI2)
3DES with Larger Key (UBCHI2)
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day (Terry Ritter)
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day (S.T.L.)
Re: one time pad ("Douglas A. Gwyn")
Re: one time pad ("Douglas A. Gwyn")
Re: 3DES with Larger Key (fungus)
Re: ElGamal without exponent reduction? (David A Molnar)
Re: 3DES with Larger Key (Bill Unruh)
Re: one time pad (Terry Ritter)
Re: one time pad (S.T.L.)
Re: "Breaking" a cipher (JPeschel)
Re: Dundee Society ("Douglas A. Gwyn")
Re: 3DES with Larger Key ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Description of the scottNNu algorithms.....
Date: Fri, 25 Jun 1999 04:06:56 GMT
Not sure I agree with everything you said but at least you looked.
In article <[EMAIL PROTECTED]>, Anonymous
<[EMAIL PROTECTED]> wrote:
>This is a generalized description of the 'scott' algorithms, derived
>from examination of the source code for scott19u. In this description,
>all bits/bytes/blocks read left to right (first to last) starting with
>index 1. I may not have it all _exactly_ right, but if not, I'm _very_
>close.... Figures would help the explaination, I'm sure, but I still
>have a headache from looking at the code.... The code itself, in
Take an asprin.
>addition to being very hard to read, is in many places very inefficient
>and sloppy. It may, or may not, be doing exactly what the author intends....
>
>B : block size in bits
>S : shift size in bits (0<S<B)
There is no reason for the above equation for example I have
a IDEA that is "wrapped PCBC" and I choose 11 bytes for the shift
though 8 bytes is the block size. So not sure if rest of constrants
really mean that much. But thanks for attempting to look at it for
scott19u.zip But in reality the lazy ivory tower types will learn
nothing from this since it is not the kind of real crypto they work
with.
>R : number of rounds
>E/D : B-bit block encryption/decryption algorithm (note that this is
>where the key comes in)
>
>L : Message length in bits
>N : number of B-bit blocks in the (padded) message
>M : the number of bits needed to pad the message to an even number of
>B-bit blocks (B*N=L+M)
>P[n] : the nth B-bit block of the plaintext (n ranges from 1 to N
>inclusive, with block N possibly partial)
>C[n] : likewise for the ciphertext
>^ : xor
>+/- : addition/subtraction modulo 2**B
>
>****************************************************
>Encryption:
>****************************************************
>Step 1:
>'Whiten' the plaintext by P[n]=P[n]^K[n] for n = N through 2 where
>K[N]=E(P[1])^E(E(P[1])) and K[n]=E(K[n-1]). Note that the first block
>is not changed.
>
>(Perform Steps 2 and 3 R times)
>
>Step 2:
>Compute C[n]=E(C[n-1]^P[n]+P[n+1]) for n = 1 through N-1 (in that order)
>(When computing C[1], use the last B bits of the unpadded message where
>C[0] would be called for)
>
>Step 3:
>Finishing up the last partial block is a little tricky. Two cases:
>
>Case A) If M<=S
>
>Step 3A1:
>Compute C[N] as in step 2 after appending C[1] and C[2] to the end of
>the plaintext to provide P[N] and P[N+1].
>
>Step 3A2:
>Append bits M+1 through S of C[1] to the end of the ciphertext. (note
>that bits 1 through M are encrypted in C[N])
>
>Case B) If M>S
>
>Step 3B1:
>Append the B-P bits of plaintext in P[N] to the end of the ciphertext.
>(note that this leaks a few bits of plaintext from one round to the
>next)
>
>Step 3B2:
>Append the left S bits of C[1] to the ciphertext
>
>Step 4:
>Left shift the entire encrypted message by S bits (so that left S bits
>of C[1] are discarded), leaving a ciphertext with a length of L bits.
>
A quick guess is that you have got it all messed up. You say
do 2 and 3 R times. But in reality the file is rotated(shifted as you say)
9 bits each pass so this can't be correct.
>Step 5:
>'Whiten' the ciphertext as in step 1
>****************************************************
>****************************************************
>
>****************************************************
>Decryption:
>****************************************************
>Step 1:
>'Whiten' the ciphertext by C[n]=C[n]^K[n] for n = N through 2 where
>K[N]=E(C[1])^E(E(C[1])) and K[n-1]=E(K[n]). Note that the first block
>is not changed.
>
>Step 2:
>Right shift the entire message by S bits. (so that the first S bits of
>C[1] are undefined/zero)
>
>(Perform steps 3 and 4 R times)
>
>Step 3 :
>Dealing with the last partial block (and reconstructing C[1]) is a
>little tricky. Two cases:
>
>Case A) If M<=S
>
>Step 3A1:
>Move the last S-M bits of the ciphertext to the bits M+1 through S of
>C[1] (partially reconstructing C[1])
>
>Step 3A2:
>Compute P[N] as below, using bits M+1 through B of C[1] and bits 1
>through M of C[2] for P[N+1]
>
>Step 3A3:
>Move the right M bits of P[N] to bits 1 through M of C[1] (completing
>reconstruction of C[1])
>
>Case B) If M>S
>
>Step 3B1:
>Move the last S bits of the ciphertext to the first S bits of C[1]
>(reconstructing C[1])
>
>Step 3B2:
>Move the last B-M bits of ciphertext to the first B-M bits of P[N].
>
>Step 4:
>Compute P[n]=(D(C[n])-P[n+1])^C[n-1] for n = N-1 through 1 (in that
>order) (When computing P[1], use the last B bits of the unpadded
>plaintext where C[0] would be called for)
>
>Step 5:
>'Whiten' the plaintext as in step 1
>****************************************************
>****************************************************
>
>For scott19u, B=19, S=9, R=23. The encryption algorithm is a a 19 bit
>permutation table with the property that repeated encryption of any
>value will cycle through all possible values before returning to the
>original ('single cycle'). It seems to be built by shuffling in a
>vaguely 'RC4-like' manner (I didn't examine it too closely - it didn't
>seem all that interesting). As a minor note, the actual code performs
>the S bit shift on a block-by-block basis, rather than all at once as I
>described, but as far as the function of the algorithm goes, it's the
>same thing. The partial block handling in the round
>seems _way_ too messy. I think I would just do the trick (described in
>Bruce's book - wonder if David has read it.... ;-) of appending the
I am under the impression since one is dealing with messy 19 bit
boudaries and C produces such poor code that the shift on a block
by block basis was by far more efficent then doing a 9 bit shift after
the pass. If you think Bruce has found a better way go for it. I wont
read his book if for nothing else then he has spamned me with ads for his
book and I feel spammers are a low life. But so far far people who
have critizes the S-table building and the main encyption loops have
bad mouthed it as sloppy and inefficent but for some reason when
they write the C code it is no faster than what I have. But most people
like to claim these areas are slow if so show faster or is it easer to
parrote some dribble from MR BS's book.
>last M bits of C[N-1] to the remaining plaintext and encrypting that to
>C[N] (and then overwriting the end of C[N-1] partially with C[N]),
>followed by a circular shift of the entire ciphertext by S bits to the
>left. It would be simpler, and wouldn't have the plaintext leak (in
>fact, for cases where there is no padding, this would produce the same
>output as the existing code). Also, there's no reason you couldn't do
>this with DES, or something else, for the encryption algorithm.
>
>Enjoy. Seek balance.
>
>
>Ras Algethi
>
that is true you could use wrapped PCBC with DES.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Kryptos article
Date: Fri, 25 Jun 1999 03:23:30 GMT
Jim is your program available? If not will you
make it so? Done in perl?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: VIC cipher now described on web site
Date: 25 Jun 1999 03:48:36 GMT
That cipher must have been a Soviet red herring. There is no way to implement
a hand cipher of that complexity.
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: 3DES with Larger Key
Date: 25 Jun 1999 03:45:48 GMT
Can 3DES be implemented with 3 independent keys of 1000+ in length each. Why
the 56 limit?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
Date: Fri, 25 Jun 1999 05:13:14 GMT
On Fri, 25 Jun 1999 00:43:53 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>In a recent post, Terry Ritter used a novel argument to show that even
>the one-time-pad is not provably secure, and that excluding "obviously
>weak" output from a true random number generator would not change
>this.
>
>For any given pad of true random numbers, one can't prove that it
>doesn't correspond to the output of a stream cipher that the
>cryptanalyst one is facing might solve!
>
>Well, I demolished his argument (as I understood it) by noting that if
>the number of possible messages is N, the probability of this
>happening is 1/N the probability of the cryptanalyst obtaining a false
>plaintext this way: hence, nothing has happened to reduce uncertainty
>concerning the plaintext.
I'm glad you are feeling so pleased with yourself, John, but that was
*not* my argument.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (S.T.L.)
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
Date: 25 Jun 1999 05:19:56 GMT
<<For any given pad of true random numbers, one can't prove that it
doesn't correspond to the output of a stream cipher that the
cryptanalyst one is facing might solve!>>
Even if that WAS his argument (which I doubt), there are an infinite number of
possible stream ciphers, and if it is a true OTP then nothing special has
happened.
Sheeeeesh.
-*---*-------
S.T.L. ==> [EMAIL PROTECTED] <== BLOCK RELEASED!
~~~ My quotes page is at: http://quote.cjb.net ~~~ 2^3021377 - 1 is PRIME!
~~~ My main website is at: http://137.tsx.org ~~~ F0 0F C7 C8
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!"
I have released my E-mail block. Address is correct as it is. I believe the
courtesy of providing a correct E-mail address is more important than having
to delete junk, which gets through anyway. The block will simply go up again
if I am bombed again. I don't care, and it's an easy solution. If you see a
message of mine posted on two newsgroups, then it is because I have replied
to a crossposted message. I *never* crosspost of my own accord!
This signature contains 3910 bits of entropy.
-*---*-------
Patiently awaiting the launch of Gravity Probe B
Card-holding member of the Great SRian Conspiracy
Card-holding member of the Dark Legion of Cantorians
Avid watcher of "World's Scariest Warp Accidents"
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 05:15:11 GMT
John Savard wrote:
> But in real life, our RBG might generate all zeroes because of a
> short circuit, ...
Yes, that was the idea of the FIPS-140 tests, which weren't allowed to
monitor the "internals" of the key generator but only the key stream.
However, you're switching context. The fellow was claiming that
patterns should be eliminated from the output of a *correctly
functioning* random bit generator to improve security, and *that*
idea is completely wrong.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 05:24:48 GMT
Here is a further argument, in case there is still any doubt:
Suppose, as before, that we can definitely assume that the OTP system
is functioning correctly. And suppose that we intercept the following
*ciphertext* from that system:
RETREAT MONDAY
Can we assume that the plaintext is
RETREAT MONDAY
and that the key stream was all-0 for that message?
The answer is: No! The message is just about as likely to be
ADVANCE SUNDAY
with whatever key stream it takes to connect this plaintext with the
ciphertext. The fact is, whatever relative likelihoods we would
have assigned to all possible messages before intercepting that
ciphertext *remain* our best estimate of the relative likelihoods of
the various messages. We learn nothing at all from the ciphertext.
That it appears to be valid English text is just one of those
coincidences that arise purely by chance, at whatever rate basic
probability theory tells us they should occur.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: 3DES with Larger Key
Date: Fri, 25 Jun 1999 09:15:39 +0200
UBCHI2 wrote:
>
> Can 3DES be implemented with 3 independent keys of 1000+ in length each.
No.
> Why the 56 limit?
Learn how the algorithm works and you'll find out why. The people
who designed DES didn't want it to be capable of using more bits.
The same happens with SkipJack, which they intended to replace
DES a couple of years ago. This has a key size of 80 bits and
all attempts to expand this size failed.
They control the key size, not us.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: ElGamal without exponent reduction?
Date: 25 Jun 1999 04:00:46 GMT
Bodo Moeller <[EMAIL PROTECTED]> wrote:
B
> Each signature provides the attacker with an equation
> s_i = a * h_i + k_i * g_i
> where s_i, k_i, and g_i are known. At first sight, the number of
> equations k will always be less than the number of unknowns
> (a, h_1, ..., h_k), but the attacker can reduce each equation modulo
> g_i, or modulo some factor f_i thereof, giving
> s_i = a * h_i mod f_i,
> and thus (if f_i can be so chosen as to make h_i invertible)
> a = s_i / h_i mod f_i.
> Obtain enough samples, use the Chinese Remainder Theorem, and you
> have a.
You know, if you phrase it that way, it sounds almost like one
of these problems amenable to solution via embedding in a lattice
and approximating with LLL. Perhaps that could be one way of
figuring out how many is "enough samples".
Thanks for for pointing this out.
-David Molnar
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: 3DES with Larger Key
Date: 25 Jun 1999 07:17:35 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (UBCHI2)
writes:
>Can 3DES be implemented with 3 independent keys of 1000+ in length each. Why
>the 56 limit?
Because tht is how DES is designed. You cannot use keys of 1000+ in
length since DES will ignore all but the first 8 bytes (7 bits plus
parity)
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 06:55:33 GMT
On 25 Jun 1999 05:34:23 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (S.T.L.) wrote:
>[...]
>Now, IF you suspect that your true-RNG is going flaky on you (operating
>incorrectly), take it out of service, have it output a quadrillion bits and run
>*statistical tests* on those bits. If it turns out to be flaky, then you can
>safely discard it knowing that the chances of it actually being good are lower
>than your chances of being hit by a meteorite while being struck by lightning.
Fine.
>If it turns out to pass those statistical tests, you can safely use it knowing
>that the chances of it actually being flaky are lower than your chances of
>being hit by a meteorite while being struck by lightning.
Unfortunately, no, and that is the problem. Statistical tests only
measure specific forms of weakness. Correlations or predictabilities
can exist which the usual statistical tests will not detect. (Or if
there is a proof to the contrary, I would like to see it.) If we
become aware of any particular problem, we can design a statistical
test for that problem, but we could never test all possible problems,
because there are too many possibilities.
Any time we can repeatedly get a significant statistical result, we
can state that a generator is weak. But not getting such results does
*not* show that a generator is strong, even in the usual statistical
sense, for it may be weak in some way other than the thing we test.
And if we do not test for a particular form of weakness, we surely
have no evidence as to the probability of that weakness occurring.
A similar situation also occurs in ciphers.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (S.T.L.)
Subject: Re: one time pad
Date: 25 Jun 1999 05:34:23 GMT
This thread is disgusting. Most involving OTPs get ugly, but *so* many kooks
posting here have the wrong ideas. I'll just state it plainly:
If you have a perfect random number generator that is operating correctly, then
ALL you need to do is take its output, send it to the recipient securely, and
then XOR said output with the plaintext, and send that over on an unsecure
channel. No munging/filtering/adulterating of the true RNG's output is
required. In fact, any filtering/adulterating/munging of the output will WEAKEN
the complete strength of the OTP to something worse.
Let me repeat that a little differently. It doesn't matter if you talk about
"all zeros" or "patterns" in the true-RNG's output. Possible stream ciphers
have nothing to do with it. Munging the true-RNG's output will weaken security,
period.
If you don't realize that what I'm saying is true, you don't understand
cryptography.
Now, IF you suspect that your true-RNG is going flaky on you (operating
incorrectly), take it out of service, have it output a quadrillion bits and run
*statistical tests* on those bits. If it turns out to be flaky, then you can
safely discard it knowing that the chances of it actually being good are lower
than your chances of being hit by a meteorite while being struck by lightning.
If it turns out to pass those statistical tests, you can safely use it knowing
that the chances of it actually being flaky are lower than your chances of
being hit by a meteorite while being struck by lightning.
Moo moo kabubu. If I've forgotten an assumption here, or said something wrong
(gasp!) feel free to point it out. I can tell kooks from the intelligent
people, and I'll only bother replying if an intelligent person notes a true
mistake/omission I've made.
-*---*-------
S.T.L. ==> [EMAIL PROTECTED] <== BLOCK RELEASED!
~~~ My quotes page is at: http://quote.cjb.net ~~~ 2^3021377 - 1 is PRIME!
~~~ My main website is at: http://137.tsx.org ~~~ F0 0F C7 C8
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!"
I have released my E-mail block. Address is correct as it is. I believe the
courtesy of providing a correct E-mail address is more important than having
to delete junk, which gets through anyway. The block will simply go up again
if I am bombed again. I don't care, and it's an easy solution. If you see a
message of mine posted on two newsgroups, then it is because I have replied
to a crossposted message. I *never* crosspost of my own accord!
This signature contains 3910 bits of entropy.
-*---*-------
Patiently awaiting the launch of Gravity Probe B
Card-holding member of the Great SRian Conspiracy
Card-holding member of the Dark Legion of Cantorians
Avid watcher of "World's Scariest Warp Accidents"
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: "Breaking" a cipher
Date: 24 Jun 1999 14:58:41 GMT
>[EMAIL PROTECTED] writes:
>What is reasonable? A year? A decade? No I think you are wrong. A
>break is a break. Imagine a safe. You could blow the door off it
>which would consitute a 'break' or you could try all combos which would
>be a brute force search. When you close the safe and forget the combo
>the safe is just as 'safe' as it was before that happend. Same for
>block ciphers. Just because you found one DES key doesn't mean you
>have them all.
>
>NOW HERE THIS, I have broken all AES ciphers. I used this new
>technique called Brute Force. This is when I try all keys and I try to
>find usefull plaintext. It works against all AES ciphers, so they are
>all broken. (fine print = Will take 10^38 years to complete, but for me
>that's reasonable.)
>
>
Reasonable could be a year I suppose. Think what you want -- I won't stop ya
kiddo, but you seem to be confusing a brute-force attack with a successful
brute-force break. (You might want to check out the phrase "computationally
infeasible," too.) With DES the entire the keyspace can searched in 2 days or
less.
You also seemed confused by the difference between an academic break
and a real-world break. Schneier, for exapmple, points out that even though
"brute-force might require 2^128 encryptions; an atack requiring 2^110
encryptions would be considered a break." This is an academic break, not
real-world break. Let's suppose the attack required even fewer,
2^80,encryptions.
We still have an academic break. Now, if, in the real world, Tommy sees
this new break and sets about implementing the attack, I will likely be calling
him Methuselah before he is ever finished with the "break." *
When Tommy has completed his little chore, he will find he has decrypted only
one message, and that he needs a shave, and, quite possibly, a strong drink
before
breaking the second message. Ironically enough for Tommy, I had the plaintext
messages that Tommy worked on. The messages included definitions of break,
academic break, and successful brute-force attack.
As it happens, I also encrypted those messages with DES. I arranged for
some time for Tommy to use EFF's DES cracker. He declined, knowing that
a brute-force break was not really a break.
*Tommy and I plan to live a long time.
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Dundee Society
Date: Fri, 25 Jun 1999 05:50:36 GMT
Jim Gillogly wrote:
> From stories leaking out of the Fort, it seems that Lambros D.
> Callimahos, main author of the indispensible Military Cryptanalytics,
> was the founder of the Dundee Society, of which all students of his
> advanced course were automatically members. It was named after the
> James Keiller & Sons Dundee Orange Marmalade crock in which he kept
> his pencils; I don't know what it looked like, since there have been
> around a dozen styles over the years. Evidently he was quite
> eccentric, and perhaps went overboard in doing more and more detailed
> background for the Zendian Problem, one of the primary study sets for
> the advanced cryptanalysis course. I would guess it's the same
> syndrome experienced by serious D&D dungeonmasters. Having pretty
> much finished the Zendian Problem, I figured if I were going to be
> a serious amateur cryppie, I'd need a Dundee crock... my "outfit", as
> it were. E-Bay obliged with an antique one.
If anybody is entitled to honorary membership, it would be Jim.
> More details, please?
That's essentially all there is to that story, except I haven't heard
that LDC was particularly "eccentric". (That rumor may have originated
in NSA's attempt to distance themselves from his work on communication
with extraterrestrial intelligence, which he seems to have gotten
started on as an invited participant in a colloquium or Senate hearing.
I have those documents and plan to put them up on my Web site, if I
ever get it going. Some of them are available as bitmaps on the NSA's
site in the FOIA released-document section.) I think the DS held
occasional meetings, just so these people could chat about their common
interest.
LDC wrote many tutorial articles for the NSA Tech. J. (later the
Cryptologic Quarterly) and as monographs on "classical" C/A topics
(as opposed to advanced mathematical methods), many of which were
assembled into a third Part of MilCryp, most of which remains
classified (wrongly, in my opinion, but I have to abide by the rules).
John Gilmore (EFF) got a heavily redacted version released via the
FOIA, a copy of which is in the National Cryptologic Museum's library,
but the released portions don't say much that isn't available from
other sources (which is probably why they were considered releasable).
There were going to be several additional Parts of MilCryp, as listed
in the published volumes, but LDC died before they were completed.
LDC was also a professional concert flautist (what do you call a
piccolo-ist?), and last time I looked, one of his recordings was
still available on CD-ROM.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 3DES with Larger Key
Date: Fri, 25 Jun 1999 05:51:48 GMT
UBCHI2 wrote:
> Can 3DES be implemented with 3 independent keys of 1000+ in length
> each. Why the 56 limit?
Maybe it has something to do with the fact that each of the 3 DES
phases uses a 56-bit key; that's how DES *is*.
------------------------------
** 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
******************************
