Cryptography-Digest Digest #345, Volume #10 Fri, 1 Oct 99 14:13:03 EDT
Contents:
Re: Example of a one way function? (Patrick Juola)
Re: Example of a one way function? (Tim Tyler)
Mathematica Notebooks ("Wm Hawthorne")
Re: EAR Relaxed? Really? ("karl malbrain")
Re: New Export Regulations (Paul Koning)
Re: Brute forcing salt instead of storing it (Was: Increasing password ("Thomas
J. Boschloo")
Are small block sizes less secure? ("Thomas J. Boschloo")
Re: Cryptanalysis of 2 key TDES (Jerry Leichter)
Re: proof ("Robert L. Ward")
Re: Random number generation (Mok-Kong Shen)
Re: security: stream cipher (Medical Electronics Lab)
Re: Are small block sizes less secure? (Scott Nelson)
authenticating an executing binary (Todd Owen)
Re: EAR Relaxed? Really? ("karl malbrain")
Re: hidden channel in Peekboo (wtshaw)
Re: Are small block sizes less secure? (SCOTT19U.ZIP_GUY)
Re: Hardest ever ECDL solved by INRIA researcher and 195 volunteers (Medical
Electronics Lab)
Secure hash function question (Aristides Kritidakis)
Re: authenticating an executing binary ("karl malbrain")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Example of a one way function?
Date: 1 Oct 1999 11:47:21 -0400
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Boris Kolar <[EMAIL PROTECTED]> wrote:
>: Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>:> Boris Kolar <[EMAIL PROTECTED]> wrote:
>:> : Roger Carbol <[EMAIL PROTECTED]> wrote in message
>:> :> I. Michael Mandelberg <[EMAIL PROTECTED]> wrote:
>
>:> :> > Can someone point me to a one-way-function that is typically used
>:> :> > for encryption?
>:> :>
>:> :> Multiplication.
>:>
>:> : Of course multiplication is a one-way function, but It's not a very
>:> : conveniant one.
>:>
>:> Multiplication is a one-way function? I'd have thought it was
>:> generally eminently reversible.
>
>: Multiplication (in the field of integers) is believed to be one-way:
>
>Well, yes - if you get two primes and throw them away after the
>multiplication. Multiplication usually has a simple inverse
>operation, though - namely division.
>
>:> I think you need to invoke complex numbers, or modulo arithmetic,
>:> or *something* if you want to claim multiplication as a one-way
>:> function.
>
>: No. Multiplication of complex numbers is easily invertible.
>
>No. a x i = -1. What is a?
Isn't this a bad example? a == i, of course. I think what you meant
is that a * a = -1, which (of course) has two solutions.
>Multiplication of complex numbers and modulo multiplication are examples
>of "completely" one-way functions that *destroy* information - and have
>no unique inverses.
Again, this is incorrect -- there's a unique inverse for every element
(mutter mutter except zero) in any field -- that's part of the
definition of field.
Or, alternately : a * 3 = 1 (mod 7)
If your cryptographic system isn't set up so that 5 and 12 produce
different values, then the information destroyed is irrelevant and
immaterial -- and in the complex plane (a * a = -1, solve for
i, and it doesn't matter if you get the sign right) multiplication
is indeed easily invertable.
-kitten
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Example of a one way function?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 1 Oct 1999 15:23:52 GMT
Boris Kolar <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Boris Kolar <[EMAIL PROTECTED]> wrote:
:> : Roger Carbol <[EMAIL PROTECTED]> wrote in message
:> :> I. Michael Mandelberg <[EMAIL PROTECTED]> wrote:
:> :> > Can someone point me to a one-way-function that is typically used
:> :> > for encryption?
:> :>
:> :> Multiplication.
:>
:> : Of course multiplication is a one-way function, but It's not a very
:> : conveniant one.
:>
:> Multiplication is a one-way function? I'd have thought it was
:> generally eminently reversible.
: Multiplication (in the field of integers) is believed to be one-way:
Well, yes - if you get two primes and throw them away after the
multiplication. Multiplication usually has a simple inverse
operation, though - namely division.
:> I think you need to invoke complex numbers, or modulo arithmetic,
:> or *something* if you want to claim multiplication as a one-way
:> function.
: No. Multiplication of complex numbers is easily invertible.
No. a x i = -1. What is a?
Multiplication of complex numbers and modulo multiplication are examples
of "completely" one-way functions that *destroy* information - and have
no unique inverses.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Microwave hint #3: make a hole in the turtle's shell first.
------------------------------
From: "Wm Hawthorne" <[EMAIL PROTECTED]>
Subject: Mathematica Notebooks
Date: 1 Oct 1999 15:15:48 -0000
I have stored a couple of Mathematica notebooks which demonstrate the RSA
and El Gamal algorithms in action using some built-in functions and the
large integer capabilites of Mathematica.
They are somewhat low-level, but very effective for instruction and
experimentation. Key lengths of 2^255 and larger are easily worked with.
One doesn't have to worry about a^b mod c algorithms or inverse modulus,
because these functions are built in. I believe this facilitates learning.
The address of the routines is:
http://members.tripod.com/SlickDude/Cryptography/ . Windows users will want
to left-click on the desired zip files. Do not right-click!!! For some
reason Tripod has problems if you try to download with right-click.
Over time I will create some more notebooks demonstrating other algorithms.
To avoid spam I have fudged with the return address of this posting. Please
post all replies to the newsgroup. Email replies will not reach me.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Fri, 1 Oct 1999 09:32:37 -0700
Greg <[EMAIL PROTECTED]> wrote in message
news:7t0td3$sdn$[EMAIL PROTECTED]...
(... OK, I give it up)
> > As you may have been following the FBI investigation of
> > the COBBS CREEK MASACRE, they determined that CRIMES
> > WERE COMMITTED AND THEY CAN FIND NO CRIMINALS. They're
> > about to start in again on WACO. Can you set this
> > straight???? How's that for position????
>
> I have no clue what you were asking me in the first place.
> If you cannot speak english like the rest of us, give it up.
In plain English:
GROUNDS is defined as a measure of POTENTIAL both by electrical engineering
OBJECTIVELY, and by legal writ SUBJECTIVELY.
Cobbs Creek is a neighborhood in Philadelphia that was FIREBOMBED by the
local police with help from the FBI. Dozens of homes were destroyed. An
investigation, led by the FBI, concluded that this was a criminal act, and
further, there were no criminals to indict.
The Waco malestrom is currently under investigation by the same Department
of Justice. What position do you have under this tyranny??? Karl M
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: New Export Regulations
Date: Fri, 01 Oct 1999 11:02:44 -0400
Mark Rosen wrote:
> ... Basically, can we now export the domestic version of Kremlin -- the full
> strength version that uses 160 bit Blowfish w/ CBC -- from the US? Do we
> have to re-apply for an export license? Did the White House just suggest
> that the regulations be changed, or have they already been changed?
As I understand it, yes, you could export that. Yes, you'd have to
apply for a new license (with one-time review). No, the rules haven't
officially changed yet, that's promised by December 15th.
See www.bxa.doc.gov for more info, and talk to your favorite export
control specialist lawyer.
paul
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: Brute forcing salt instead of storing it (Was: Increasing password
Date: Fri, 01 Oct 1999 17:35:56 +0200
Kevin Buhr wrote:
>
> [ newsgroups trimmed ]
>
> "Thomas J. Boschloo" <[EMAIL PROTECTED]> writes:
> >
> > BTW: [The idea of storing the salt is just 'lame' I think. I would just
> > concatenate the username with the password if I had written Unix. That
> > also allows the system administrator to see if a user used the same
> > password twice on two systems, and warn the user.]
>
> One problem with your scheme that comes to mind: if you collect a
> number of encrypted passwords for the same username on different
> machines, they will all obviously have the same salt, simplifying a
> dictionary attack against a particular user. This is made all the
> more problematic in the Unix world, since a certain Mr. I. M. Root
> seems to have accounts on the vast majority of the Unix machines I've
> seen. User "root"'s presence would allow the construction of huge
> pre-fabricated dictionaries on CD for cracking purposes, exactly the
> sort of thing the salt was meant to prevent (or, more accurately, make
> 4096 times more inconvenient).
>
> One could get around this by concatenating machine-specific
> information to the password, but this would render the encrypted
> passwords non-portable across machines, a big disadvantage.
I already thought of this, but discarded the idea because people that
are 'root' should be smart enough to pick a non-dictionary password. If
they aren't that smart, there will probably also be other ways to get
into their system.
The other thing is that to do a dictionary attack now, you would only
need 4096 dictionaries for every possible salt. If you used the username
as a salt, this number would be far greater as there are very many
possible user names. Not just 2^12.
I think the big advantage would be, that the pw file wouldn't be
polluted with all those salts. I am a strong believer of K.I.S.S. (Keep
it simple st*p*d), and thus think salts are really ugly..
High regards,
Thomas
--
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Are small block sizes less secure?
Date: Fri, 01 Oct 1999 17:29:35 +0200
This would probably be a very simple question to answer, but would a 256
bit 8 bit block cypher be less secure than an 256 bit, 128 bit block
cypher?
I would guess that a small block size is only disadvantagous for higher
bit processors because they can't use the whole word length on their
processor.
Regards,
Thomas
--
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: Jerry Leichter <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis of 2 key TDES
Date: Fri, 01 Oct 1999 11:21:11 -0400
| The best attack known on 2-key Triple DES is due to Wiener and
| Van Oorschot from Eurocrypt '90. If the number of known
| plaintext-ciphertext pairs is t, then the attack takes O(t) space,
| and about 2^(120 - lg(t)) steps.
That's an astounding result: Killian and Rogoway show that a brute-
force attack against DESX with t known - in fact, even chosen -
plaintext/ciphertext pairs requires 2^(118 - lg(t)) DES encryptions and
decryptions. So replacing XOR'ing before and after DES (DESX) with DES
encryption (2-key Triple DES) only gains you a factor of 4 in security!
Assuming I'm interpreting this right - it would require a careful
comparison of the attack models in the two papers - there's very little
reason to use triple-DES:
- If you believe that there are no effective attacks against
DES that are significantly better than brute force,
then 2-key triple DES and DESX are within a factor
of 4 in strength. (Note that either of these will
prevent linear cryptanalysis.)
- If you believe that there is an analytic attack against DES
that is significantly better than brute force, then
it takes considerable blind faith to believe that the
attack doesn't extend to triple-DES. Without that,
you have absolutely no reason to believe that either
DESX or triple DES has any significant strength.
-- Jerry
------------------------------
From: "Robert L. Ward" <[EMAIL PROTECTED]>
Subject: Re: proof
Date: Fri, 01 Oct 1999 11:01:59 -0400
[EMAIL PROTECTED] wrote:
> In the hill cipher how many 2x2 matrices are invertible over modulo n?
> (where n is a prime number)
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
(n^2-1)*(n^2-n).
Robert Ward
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random number generation
Date: Fri, 01 Oct 1999 18:24:57 +0200
j.w.altena wrote:
>
> At Statistics Netherlands we would like to have to our disposition about
> 10E9 random identifying numbers with a length of 10 (decimal) positions.
> These numbers should preferably not be generated all at the same moment, but
> the set should be extendable in steps. We think we can use encryption for
If I don't err, you want to have random numbers that are unique.
Since these are used in your applications for identification,
there is certainly a facility to check whether an identification
number is a valid number, i.e. whether it is associated with a
valid record in your data bases. Isn't it enough simply to generate
random numbers and check for collisions?
M. K. Shen
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: security: stream cipher
Date: Fri, 01 Oct 1999 12:25:34 -0500
[EMAIL PROTECTED] wrote:
>
> Can anyone help me:
>
> There is a concept to implement a stream cipher
> with LFSR to encode. (f.e. Geffe or Alternating
> stop-and-go generator)(with a enough long period)
> The output of the PRSG and the Data Stream are
> then xored.
>
> The problem is, that the Data Stream consists of
> a bitframe in which part of the data (header) can
> be known or puzzled.
What are you trying to protect? The header data just
tells where the packet is going, no need to encrypt
that.
>
> Therefore an attacker can get part of the key.
>
> Probably a method is to encrypt the header before real
> encryption.
Then how's it going to be delivered?
> Is it generally possible to encrypt at stream mode
> non random data with a key, which length isn't endless.
Sorry, this doesn't make sense to me.
If you are trying to prevent traffic analysis, encryption
won't help. If you're not worried about TA, then don't
encrypt anything "obvious". You'll have to mux the header
data with the encrypted packet stream so that only the
data is encrypted. That will make the attacker's task
more difficult since they'll have to know something about
your data.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Are small block sizes less secure?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 01 Oct 1999 16:29:28 GMT
On Fri, 01 Oct 1999 17:29:35 +0200, "Thomas J. Boschloo"
<[EMAIL PROTECTED]> wrote:
>This would probably be a very simple question to answer, but would a 256
>bit 8 bit block cypher be less secure than an 256 bit, 128 bit block
>cypher?
>
Codes are like chains - they're only as strong as the weakest link.
If block size was the weakest link, then a larger block size
would be more secure. But if key size was the weakest link,
then a larger block would not be. If you post the key on
the internet, then both codes are equally insecure.
Small block sizes are subject to the Code Book attack -
255 chosen plain texts and an 8 bit block is completely
known. So an 8 bit block size isn't enough unless you
know you're sending less than 16 blocks of data.
512 bits is large enough that the weakest link is certain
to be something other than block size or key size,
so there's no point in making them larger. It might not
cost anything to make it larger, but there's no advantage.
It's quite probable that less than 512 bits is enough.
Most on sci.crypt would argue that 256 is overkill,
and 128 bits is more than enough.
>I would guess that a small block size is only disadvantagous for higher
>bit processors because they can't use the whole word length on their
>processor.
>
Smaller blocks can, in general, be processed faster, but
the progression is not linear. Doubling the block size
only decreases the bits per second by about logN.
The actual amounts are highly dependant on the
actual cipher implementation, and good programming
counts a lot more than word size.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Todd Owen <[EMAIL PROTECTED]>
Subject: authenticating an executing binary
Date: Sat, 02 Oct 1999 01:30:29 +0800
hi all,
I'm pretty skeptical about this being possible, but it's an interesting
concept and I wondered if anybody had any thoughts about it. The
hypothetical situation is:
A comms link is established between a server, S, and a client program,
C, running on a remote computer. C is a program (meaning a .exe file,
for instance) that has been distributed to the user. The server wants
to verify that C is genuinely the .exe file that was distributed, down
to the last byte.
This does not mean verifying the program's digest, because you can do
that without the program actually running. The server wants a guarantee
that the program, unmodified, is running right at that moment. Clearly
this would involve some sort of challenge from the server, or a replay
attack would be easy. It sounds like it would involve not just
crytography but perhaps also something to do with the platform and the
OS and the way code executes on it. C has to generate some response
which could (god knows how) _only_ be generated by an executing,
unmodified version of the program. And best of all, S needs to verify
this response somehow.
As I say, it sounds rather tricky. The only (inadequate) substitute I
can think of is just making the program as complicated as possible, and
throwing in some checksums for good measure. And I know _exactly_ what
that constitutes - an open challenge to any cracker with some spare time
on her hands!
Thanks for getting this far!
Todd.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Fri, 1 Oct 1999 10:42:56 -0700
wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Disclosing how the evidence was obtained is important to prove that all of
> it was obtained legally. Especially, it is important in crypto to prove
> techniques, to see that a true method was used other than creative
> miscorrelation of data, or improper methods clearly denied.
Have you `monitored' where these proposals for BACK-DOOR keys, which would
by necessity remain SECRET for the FBI/NSA, keep coming from???
> On a side issue, surely if possession of some evidence is clearly wrong
> and subversive as well as being illegal, than there must also be something
> wrong with officials as well who handle or seek to handle such things, and
> they should be closely monitored afterwards for negative effects.
No, the BOLSHEVIK position on subversion is that you root-it-out and
LIQUIDATE. There's no such thing as RECTIFICATION for positive results, per
the Heisenberg uncertainty principle that you can't distinguish them
(positive results) from NEGATIVE EFFECTS.
(... the remainder snipped as ISOMORPHIC for `if you can say it, you can do
it') Karl M
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: hidden channel in Peekboo
Date: Fri, 01 Oct 1999 11:10:58 -0600
In article <7t16i8$2o4$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> I don't quite get your point.... Peekboo is very easy to setup and use. Most
> users introduce themselves by sending an email containing their public key
> and the message. If you expect for example all people who drive cars to be
> mechanics or all people who take medicine to be doctors then I think you are
> dreaming.
There are shades here worth mentioning. The problem you brought out was
that 64 bits could be used to some unuser unfriendly purpose, courtesy of
a change in the program. To prevent this from causing problems, come up
with a test if you can to demonstrate the possible hanky panky.
>
> I don't expect most users to say 'ha he uses blah blah blah' it must be
> secure. What I want is crypto people to say 'ha he uses blah blah blah this
> way ...' it must be [unproven to not be] secure. If like GM I can get
> 'quotes from experts' then that will please the mass.
It appears that some that you might see as experts does not guarantee that
they also have scruples. Show me a list of bonded experts, particularily
those that traffic in high dollar advice. Claiming to be at no risk for
the bad advice you may give at a premium is no good.
One thing the masses are used to is being lied to; treating all like sheep
rather than working hard to make matters self evident is not really
helpful. Remember, government rather favors as few people learning much
about crypto as possible; where do you stand on this?
--
Still a good idea from Einstein: If you can't explain something clearly to a child,
you do not understand it well enough.
So much for models of trust, they generally are ill-founded.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Are small block sizes less secure?
Date: Fri, 01 Oct 1999 18:48:10 GMT
In article <[EMAIL PROTECTED]>, "Thomas J. Boschloo" <[EMAIL PROTECTED]>
wrote:
>This would probably be a very simple question to answer, but would a 256
>bit 8 bit block cypher be less secure than an 256 bit, 128 bit block
>cypher?
>
>I would guess that a small block size is only disadvantagous for higher
>bit processors because they can't use the whole word length on their
>processor.
>
>Regards,
>Thomas
Actually if one limited oneself to the weak 3 leter chaining modes. You
could think of any block boc cipher as a random S-box since every thing
else is a subset of this. The key length is what every is required to
represent any such S-box I don't rember what the lenght is right off hand
but the number goes up rapidily for 4 bits it is on the order of 40 bits
while at at 8 bits I thought it was larger than 256 bits. But no matter. This
small blocked type of cypher is easy to break since for a givein key one
needs only to have 256 cipher to plain text blocks to fully discribe the
whole thing.
IF you want to calculate it find the number of bits to represent (256!)
that is the size of key necessiary.
But it is considered very weak. However maybe you would get
some dumb person to claim you can only do a dumb blind search
which is what people seem to claim for any problem in which case
the sun whould have to burn out before a soluton is found.
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: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Hardest ever ECDL solved by INRIA researcher and 195 volunteers
Date: Fri, 01 Oct 1999 12:41:34 -0500
Paul Crowley wrote:
> I had understood that the patents attached to particular optimisations
> of ECC, not all of it, and there were reasonable forms that were not
> patent encumbered. Am I wrong?
There is a patent which Certicom owns which optimizes ONB calculations
for use with ECC. They also have several patents on protocols, but
that's the use of ECC. Apple owns Next's patent which is specialized
for DH and GF(p^n) for p odd.
The basic ECC algorithms and implementations are not patented and
have been in the public domain for more than 5 years. As processing
power increases, the price of being a touch slower because you're
not using an optimal (and patented) form will make the competition
tough for those with the patents. But for those who need speed,
paying the royalties will probably be worth it.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Aristides Kritidakis <[EMAIL PROTECTED]>
Subject: Secure hash function question
Date: Fri, 1 Oct 1999 19:53:56 +0200
I understand that from the result of a secure hashfunction
it is infeasable to reconstruct its input.
However does the following hold true?
>From the results of a secure hashfunction for
sligthly different inputs, is it still infeasable to reconstruct
the invariant part?
for example having:
MD5("pericles1"), MD5("pericles2"), MD5("pericles3") ...
would it still be infeasable to find "pericles"?
============================================================
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: authenticating an executing binary
Date: Fri, 1 Oct 1999 11:07:13 -0700
Todd Owen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> hi all,
>
> I'm pretty skeptical about this being possible, but it's an interesting
> concept and I wondered if anybody had any thoughts about it. The
> hypothetical situation is:
>
> A comms link is established between a server, S, and a client program,
> C, running on a remote computer. C is a program (meaning a .exe file,
> for instance) that has been distributed to the user. The server wants
> to verify that C is genuinely the .exe file that was distributed, down
> to the last byte.
Try the CONVERSE, where the PROGRAM wants to know it's talking to the REAL
server. Then you could have the server ISSUE (via Diffie-Hellman secured
means) a unique challenge PLUG-IN to EMIT a unique 64 bit digest code based
on the actually executing program. Hope this helps, Karl M
------------------------------
** 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
******************************
