Cryptography-Digest Digest #4, Volume #12 Sun, 11 Jun 00 12:13:01 EDT
Contents:
Re: Call for evaluating and testing a stream cipher program (Paul Rubin)
Re: Random IV Generation (Tim Tyler)
Re: randomness tests (tomstd)
Re: Cryptanalytic gap [was: Re: Some dumb questions] (John Savard)
Re: Call for evaluating and testing a stream cipher program (tomstd)
Re: Call for evaluating and testing a stream cipher program (tomstd)
Re: Arithmetic Coding (Tim Tyler)
Re: Arithmetic Coding (Tim Tyler)
Re: Arithmetic Coding (Tim Tyler)
Re: Arithmetic Coding (tomstd)
Re: Twofish Idea (David Empey)
Re: randomness tests ("Trevor L. Jackson, III")
Re: Random IV Generation ("Trevor L. Jackson, III")
Re: Digits of pi in Twofish (wtshaw)
Re: Cipher design a fading field? (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Call for evaluating and testing a stream cipher program
Date: 11 Jun 2000 13:11:35 GMT
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>I did not realize that your absurd and hostile comments were "specific
>questions." If you had read my description they would not even occur to you. But
>here are the answers:
>
>1) I was not joking
>2) I do know what BBS is.
>3) I do not "post-process" it. There are several PRNGs running in parallel at
>different speeds. The BBS generates one random number for each 262144 random
>numbers generated by the fastest running LFG.
>4) That is how I can mention "fast" and "BBS" in the same context.
>
>I hope this answers your questions.
Here's a couple further specific questions for you to answer:
1) Ok, how fast is your cipher then really, in bytes/sec on a typical PC?
Whatever hardware you've timed it on is fine, just specify what it is.
2) Have you applied or do you intend to apply for any patents regarding
the cipher?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random IV Generation
Reply-To: [EMAIL PROTECTED]
Date: Sun, 11 Jun 2000 12:59:44 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
:>Instead of counting in binary sequence, use a finite field.
:>Typically, this would be a simple linear feedback shift register
:>(lfsr). There is no strength required for the counting
:>sequence; the strength improvement comes from not presenting a sequence
:>in which only one bit changes fully half the time.
: Big complicated... use a linear congruetial generator then, no
: reason to get all "high" tech ..hehehehe..
An LFSR is fantastically low tech compared to an LCG.
It's much faster in hardware - and in software - since it requires
no multiplication - and *definitely* no modulo arithmetic.
LFSRs are not renowned for being fast in software - but that's because
they output one bit at a time. When using an LFSR as a counter to drive a
block cypher, you can happily use all the bits in the register
simultaneously ;-)
Personally, I'd prefer a Hortensius-style FSM RNG to a LFSR - due to its
still further improved randomness characteristics - but since the cypher
is the primary source of strength, it doesn't matter that much.
[Hortensius, P. D., McLeod, R. D., Pries, W., Miller, D. M. and Card, H.
C., Cellular automata-based pseudorandom number generators for built-in
self test, IEEE Transactions on Computer-Aided Design, August 1989,
volume 8, number 8, pages 842-859.
Hortensius, P. D., McLeod, R. D.and Card, H. C., Parallel random number
generation for VLSI systems using cellular automata, IEEE Transactions
on Computers, 1989 volume 38, number 10, pages 1466-1473.]
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
Subject: Re: randomness tests
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 11 Jun 2000 06:16:38 -0700
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>, Tim Tyler
<[EMAIL PROTECTED]> wrote:
>:>[EMAIL PROTECTED] wrote:
>
>:>: in order to check randomness of my random number(bit)
generator
>:>: i use
>:>: 1. ent package
>:>: 2. diehard package [...]
>:>
>:>: can anyone suggest me any tests?
>:>
>:>pLab have a C++ test-suite for download: (at the bottom of)
>:> http://random.mat.sbg.ac.at/tests/
>
>: Again, total garbage. The original poster never said what he
is
>: using the prng for so how can you be sure that these tests are
>: good for what he needs?
>
>He asked for tests. I gave him a big C++ test suite.
>
>I don't see how this qualifies as total garbage.
>
>Personally, I find randomness tests very useful for
cryptographic purposes
>- by weeding out garbage. It's not terribly important what the
>application requiring randomness is - if it fails the sorts of
simple
>tests in randomness test suites, the chances of it resisting
the dedicated
>attention of an analyst seem to be pretty low.
>
>: Would people stop clinging to Diehard/ent/etc as the ONLY way
to
>: test a prng!
>
>Who ever said that!???
>
>: IF you don't know what it's for, how can you tell if it's
good or not?
>
>If they're asking for a random number generator, it's pretty
safe to
>assume that something that outputs 0,0,0,0,0,0,57,0,0,0,0,0,0
will *not*
>qualify as being "good". This is the sort of thing that a
randomness test
>will easily pick up on.
That's just ignorance now. A million zeros *could* be random
though.
I agree that some statistical tests are a good idea, but alot of
tests are contrived to destroy a particular prng. The "Birthday-
Spacing" test was designed to show that Lagged Fibonacii
generators are not random without a sufficient lag.
If you don't know what you are using the prng for, you can't
tell if it's working now can you? Simple as that.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cryptanalytic gap [was: Re: Some dumb questions]
Date: Sun, 11 Jun 2000 13:17:49 GMT
On Sun, 11 Jun 2000 06:34:24 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>John Savard wrote:
>> ... Anything that isn't an OTP can, in theory, be solved: ...
>No.
If you count brute-force methods, which I was doing in that context, I
can't immediately see where I've oversimplified.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
Subject: Re: Call for evaluating and testing a stream cipher program
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 11 Jun 2000 06:18:26 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>I did not realize that your absurd and hostile comments
were "specific
>questions." If you had read my description they would not even
occur to you. But
>here are the answers:
>
>1) I was not joking
Good for you.
>2) I do know what BBS is.
Better.
>3) I do not "post-process" it. There are several PRNGs running
in parallel at
>different speeds. The BBS generates one random number for each
262144 random
>numbers generated by the fastest running LFG.
As long as you discard the other 262144 numbers and only use the
BBS output, I think it will be ok.
>4) That is how I can mention "fast" and "BBS" in the same
context.
>
Not to mention un-scientific.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Call for evaluating and testing a stream cipher program
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 11 Jun 2000 06:23:00 -0700
After actually reading your paper, I still agree you are doing
something very wrong. You use the output of the BBS for a key
that performs some operation "F3()" on 64 outputs from LFG C,
which in turn is used as the key for F2 and so on.
The whole security of the system lies in F1/F2/F3 not the BBS
generator. I also don't see the need to make 4096/262144
outputs from LFGB and LFGA.
All in all I don't think it's a secure system or even fast.
What is the rated speed anyways?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Arithmetic Coding
Reply-To: [EMAIL PROTECTED]
Date: Sun, 11 Jun 2000 13:08:02 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: No matter how you treat the EOF, I can always just
: decrypt/decompress and test for ASCII. You can't stop a brute
: force search with compression.
That's no reason to give the attacker additional halting criteria.
Also, it's quite possible for a text compressor to only output ASCII
files.
Also, the file may not be an ASCII file in the first place -
you may not know much about what it contains at all.
This seems to have gone off the point about whether normal
Arithmetic/Huffman end-treatment "adulterates" the file.
It does so since it provides information to the analyst about whether
they have a correct decrypt which they might otherwise lack.
At worst, this knocks a few bits off the keyspace of the cypher - but why
needlessly put up with that?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Destroy Microsoft.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Arithmetic Coding
Reply-To: [EMAIL PROTECTED]
Date: Sun, 11 Jun 2000 13:22:01 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>tomstd <[EMAIL PROTECTED]> wrote:
:>Huffman symbols need not represent bytes. They can represent
:>anything you like. The same goes for arithmetic coding.
:>
:>You could even produce a 1-1 adaptive Huffman compressor that
:>works with dictionaries of strings [...]
:>
:>Comparing maximum compression ratios on different types of data
:>is an almost totally useless way of comparing compressors.
: My point was that on virtually all types of data string
: compressors outperform symbol encoders. This is nothing new.
: Therefore it's reasonable to assume after compression with say
: LZSS there are closer to 64 bits of info per '64-bit block' of
: plaintext.
This might be a valid criticism of David Scott's compressor.
It does not appear to me to apply to Huffman coding schemes in general,
since the Huffman coding scheme describes how symbols are represented in
the compressed data stream, and says little about what those symbols
represent. It's quite possible for Huffman symbols to translate into
variable-length symbol strings in the output.
: As for a brute force search, if your compressor is reversible
: then I can still recognize valid plaintext. This doesn't make
: brute force search any faster no matter what the input is.
It certainly can do. You assume - incorrectly - that the analyst
will always know of halting criteria which will uniquely locate the
correct decrypt from all the possible ones.
There are many cases where this assumption is false. Consider if the
message is very short - not much longer than the key. In this case we
have a situation much like an OTP - *many* possible decrypts are plausible
messages.
Consider also the case where the compressor is very efficient on its
target data. In such cases very many possible decrypts will look like
plausible message. It's easy to imagine such a scheme for (say)
bank account number details.
Use of poor compression might reveal a unique plaintext - even if the
data being transmitted is in fact totally random - and would normally
offer no clues at all to the cryptanalyst.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Arithmetic Coding
Reply-To: [EMAIL PROTECTED]
Date: Sun, 11 Jun 2000 13:34:25 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: My point which I will re-iterate for the 100th time is
: that "huffman compression is inefficient and can pack less
: information per bit of plaintext" which is a very powerful dis-
: proof for your theory. Your theory is that the other
: compression algorithms leave information about the plaintext
: (redundant information) in the compressed data stream. My
: counterproof is that this is not possible if they are MORE
: EFFICIENT.
So, your argument is that because squeezer X squeezes more than squeezer
Y, squeezer X leaves absolutely no trace of fat remaining???!
What sort of logic is that!?
The situation is that both types of compressor leave clues if used on
data-types for which they are sub-optimal.
David Scott's compressor fails to squeeze many typical types of data as
well as it could do. Consequently, it leaves remaining clues in the
compressed file.
Other compressors do this as well, to varying degrees.
They also allow compressed files to be distinguished from random files
that result from a typical decryption with an incorrect key. They do this
*regardless* of the original plaintext - and the invalidity of the file
can be easily detected in an automated manner without any assumptions
about the frequency distribution of characters in the plaintext.
I see no insurmountable technical reason why /extremely/ efficient 1-1
compressors should not be constructed. Indeed, through not wasting
information, the very best compressors should eventually exhibit David
Scott's 1-1 property.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
Subject: Re: Arithmetic Coding
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 11 Jun 2000 06:56:49 -0700
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>: No matter how you treat the EOF, I can always just
>: decrypt/decompress and test for ASCII. You can't stop a brute
>: force search with compression.
>
>That's no reason to give the attacker additional halting
criteria.
>
>Also, it's quite possible for a text compressor to only output
ASCII
>files.
>
>Also, the file may not be an ASCII file in the first place -
>you may not know much about what it contains at all.
>
>This seems to have gone off the point about whether normal
>Arithmetic/Huffman end-treatment "adulterates" the file.
>
>It does so since it provides information to the analyst about
whether
>they have a correct decrypt which they might otherwise lack.
>
>At worst, this knocks a few bits off the keyspace of the
cypher - but why
>needlessly put up with that?
What the heck are you talking about? Compression doesn't *add*
redundant bits to the output. That would be lunacy.
And even still. If your methods are deterministic I can always
check for valid solutions, no matter what codec you use. You
don't make sense at all.
Compression is only to make messages SMALLER not more random.
Making them appear random is a CONSEQUENCE of compression not
the goal (well sorta). The goal is to remove redundancy, and by
doing this you make the codec stream look random.
And my previous point is still valid (LZSS compress better). So
I really don't see how you guys can continue this argument.
Face it, pure arithmetic compression on a desktop is a STUPID
idea since it's not efficient. Use an appropriate codec, like
deflate for general purpose data.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: David Empey <[EMAIL PROTECTED]>
Subject: Re: Twofish Idea
Date: Sun, 11 Jun 2000 07:47:58 -0700
Reply-To: [EMAIL PROTECTED]
tomstd wrote:
>
> The 'g' function itself is just
>
> g(a) --> mds(a) --> bytesub(a) -->
Maybe I'm misreading your notation, but I think you've got the
mds and byte substitution in the wrong order.
>
> Where mds() and bytesub() are the same for either g or g'. The
> purpose of the mds is to linearly (in GF(2)) mix the 4 byte
> input vector so that there is a high avalanche.
>
> However I don't think the data path is entirely optimal because
> the 64-bit input is split into two halves the diffusion is at
> most on one half of the input. If for example it achieves ideal
> diffusion in 'g' then only 16 of the 64 output bits will flip on
> average, not 32. Even through the PHT which should make the
> figure closer to 32 the bits that flip will be related in
> position.
>
> Ideally they should have used a 8x8 MDS and 8 unique sboxes.
> This could be precomputed as eight 8x64 sboxes and xor them
> together. This would increase the memory and execution time,
> but have a more ideal data path.
If you read the Twofish paper (or book) you'll see that they
did consider this design, but decided it would be too slow.
--
Cordially,
Dave Empey
------------------------------
Date: Sun, 11 Jun 2000 11:40:30 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: randomness tests
tomstd wrote:
> In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
> wrote:
> >tomstd <[EMAIL PROTECTED]> wrote:
> >: In article <[EMAIL PROTECTED]>, Tim Tyler
> <[EMAIL PROTECTED]> wrote:
> >:>[EMAIL PROTECTED] wrote:
> >
> >:>: in order to check randomness of my random number(bit)
> generator
> >:>: i use
> >:>: 1. ent package
> >:>: 2. diehard package [...]
> >:>
> >:>: can anyone suggest me any tests?
> >:>
> >:>pLab have a C++ test-suite for download: (at the bottom of)
> >:> http://random.mat.sbg.ac.at/tests/
> >
> >: Again, total garbage. The original poster never said what he
> is
> >: using the prng for so how can you be sure that these tests are
> >: good for what he needs?
> >
> >He asked for tests. I gave him a big C++ test suite.
> >
> >I don't see how this qualifies as total garbage.
> >
> >Personally, I find randomness tests very useful for
> cryptographic purposes
> >- by weeding out garbage. It's not terribly important what the
> >application requiring randomness is - if it fails the sorts of
> simple
> >tests in randomness test suites, the chances of it resisting
> the dedicated
> >attention of an analyst seem to be pretty low.
> >
> >: Would people stop clinging to Diehard/ent/etc as the ONLY way
> to
> >: test a prng!
> >
> >Who ever said that!???
> >
> >: IF you don't know what it's for, how can you tell if it's
> good or not?
> >
> >If they're asking for a random number generator, it's pretty
> safe to
> >assume that something that outputs 0,0,0,0,0,0,57,0,0,0,0,0,0
> will *not*
> >qualify as being "good". This is the sort of thing that a
> randomness test
> >will easily pick up on.
>
> That's just ignorance now. A million zeros *could* be random
> though.
>
> I agree that some statistical tests are a good idea, but alot of
> tests are contrived to destroy a particular prng. The "Birthday-
> Spacing" test was designed to show that Lagged Fibonacii
> generators are not random without a sufficient lag.
>
> If you don't know what you are using the prng for, you can't
> tell if it's working now can you? Simple as that.
Tom,
There's a point here that you are missing. It's about judgments. The most
obvious source of judgments is a judge in a courtroom. Look at the kind of
judgments that come from criminal courts: you either get guilty or not guilty.
You never get a judgment of innocent.
The same thing happens when you test a cipher or a PRNG. You attack (prosecute)
the system by looking for bad behavior (crimes). The result is either guilty
(of the crime charged) or not guilty (_of_the_crime_charged_). You never get a
result of good (of all crimes).
This misunderstanding leaves you in the position of making incorrect
evaluations. Consider the statement "If you don't know what you are using the
PRNG for, you can't tell if it's working...".
In fact if I _do_ know what I am using a system for I can't test for the
system's ability to deliver. Say the PRNG is used for whitening. I want a flat
distribution over all possible spaces. But that condition is not testable. So
I test the distributions over a representative sample of spaces, producing a
result of bad (in a subset of the sample spaces), or not bad (in the set of
spaces tested). If the result of the test finds no distortion, it does not
permit me to conclude that the distribution is flat in all spaces. It is
suggestive, but not conclusive.
This is exactly analogous to the concept of cipher strength. When we
test/attack/prosecute a cipher we can't conclude from a failed attack that the
cipher is strong. Only a successful attack gives a conclusive result -- of
weakness. So, just as we want a cipher that resists all known attacks, we would
want a PRNG that passes all known statistical tests.
Think of it as a probabilistic test of goodness. Any counterexample is
conclusive. Any example is merely suggestive. So we collect all the
suggestions we can find.
------------------------------
Date: Sun, 11 Jun 2000 11:45:54 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random IV Generation
Tim Tyler wrote:
> tomstd <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
> :>Instead of counting in binary sequence, use a finite field.
> :>Typically, this would be a simple linear feedback shift register
> :>(lfsr). There is no strength required for the counting
> :>sequence; the strength improvement comes from not presenting a sequence
> :>in which only one bit changes fully half the time.
>
> : Big complicated... use a linear congruetial generator then, no
> : reason to get all "high" tech ..hehehehe..
>
> An LFSR is fantastically low tech compared to an LCG.
>
> It's much faster in hardware - and in software - since it requires
> no multiplication - and *definitely* no modulo arithmetic.
>
> LFSRs are not renowned for being fast in software - but that's because
> they output one bit at a time. When using an LFSR as a counter to drive a
> block cypher, you can happily use all the bits in the register
> simultaneously ;-)
You can implement an LFSR in software that outputs a full word at a time. You just
need a tap arrangement that eliminates inefficient dependencies.
>
>
> Personally, I'd prefer a Hortensius-style FSM RNG to a LFSR - due to its
> still further improved randomness characteristics - but since the cypher
> is the primary source of strength, it doesn't matter that much.
>
> [Hortensius, P. D., McLeod, R. D., Pries, W., Miller, D. M. and Card, H.
> C., Cellular automata-based pseudorandom number generators for built-in
> self test, IEEE Transactions on Computer-Aided Design, August 1989,
> volume 8, number 8, pages 842-859.
>
> Hortensius, P. D., McLeod, R. D.and Card, H. C., Parallel random number
> generation for VLSI systems using cellular automata, IEEE Transactions
> on Computers, 1989 volume 38, number 10, pages 1466-1473.]
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Digits of pi in Twofish
Date: Sun, 11 Jun 2000 09:05:54 -0600
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> tomstd wrote:
> >
> > it's blowfish not twofish that uses pi, and there is absolutely
> > no cryptographic reason to the best of my limited knowledge
>
> 'Transparency' is a good cryptographic reason. "See, we're using
> a pile of bits in here, but there's no back door -- honest. You
> can verify for yourself that it's the most obvious pile of bits in
> all of mathematics."
>
> --
> Jim Gillogly
> Hevensday, 22 Forelithe S.R. 2000, 04:48
> 12.19.7.5.2, 2 Ik 5 Zotz, Third Lord of Night
True enough about pi. The choice of value is just another key after all.
It could be some other constant just as well, the length used, the length
of that key. Suppose that a simple reassignment of another constant, or
jumble of bits of sufficiennt, makes another cipher: There could be a
whole aquarium of alternates.
--
Hippocracy is claiming that since you are MS Certified you can
speak about good security.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cipher design a fading field?
Date: Sun, 11 Jun 2000 09:16:15 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Cryptosystems form a highly constrained subclass of the class of
> all possible programs. Consider that the encryption function has
> to take an arbitrary plaintext and produce a unique corresponding
> ciphertext that has the property that it will be mapped back to
> the original plaintext using a fixed decryption function that
> depends only on the encryption function. Very few programs come
> anywhere close to meeting this requirement.
>
Scientific restraint is based on the natural order of things, not as
someone wants them to be.
Yes, very few programs meet the requirement you suggest, which can be,
together with other aspects, a definite contribution to strength,
obviously including none designed with prior restraint in mind.
--
Hippocracy is claiming that since you are MS Certified you can
speak about good security.
------------------------------
** 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
******************************
