Cryptography-Digest Digest #509, Volume #12 Tue, 22 Aug 00 21:13:01 EDT
Contents:
Re: Re-using CD-R discs (Eric Smith)
Re: Re-using CD-R discs ([EMAIL PROTECTED])
Re: Re-using CD-R discs ("Seeker")
Re: My unprovability madness. (Future Beacon)
Comment from Hardware Experts Please ([EMAIL PROTECTED])
Re: Kryptos and Gillogly ("Douglas A. Gwyn")
Re: Bytes, octets, chars, and characters (Paul Schlyter)
Re: Bytes, octets, chars, and characters (Mark McIntyre)
Secret-sharing algorithm ([EMAIL PROTECTED])
Re: blowfish problem ("Kelsey Bjarnason")
Re: Secret-sharing algorithm ([EMAIL PROTECTED])
Re: What is required of "salt"? (David A. Wagner)
Questions about stream cipher ("Miki Watts")
Re: My unprovability madness. (Steve Leibel)
Re: Questions about stream cipher ([EMAIL PROTECTED])
Re: 1-time pad is not secure... (Tim Tyler)
Re: 1-time pad is not secure... (Tim Tyler)
Re: 1-time pad is not secure... (Tim Tyler)
Re: Crypto Coprocessor on Javacard (Eric Murray)
SSL protocol and unencrypted random info ([EMAIL PROTECTED])
Re: Decryption (John Savard)
----------------------------------------------------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: Re: Re-using CD-R discs
Date: 22 Aug 2000 15:16:54 -0700
Sark <[EMAIL PROTECTED]> writes:
> I have heard some rumours about being able to erase CD-R discs by
> baking them in the oven. Someone said it was 220 degrees for 10 min. I
> tried it, but it didn't work. Any suggestions?
If the CD-R was still readable after this process, try again with a higher
temperature. I have no doubt that there is some temperature sufficiently
high to erase the CD-R.
You subject line said "re-using", though. If you mean re-using to store
data, I doubt you'll have much luck.
If you want reusable discs, you're much better off just buying CD-RW in
the first place.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Re-using CD-R discs
Date: Tue, 22 Aug 2000 22:18:39 GMT
In article <39a2ec60$0$62234$[EMAIL PROTECTED]>,
Sark <[EMAIL PROTECTED]> wrote:
> I have heard some rumours about being able to erase CD-R discs by
baking them in the oven. Someone said it was 220 degrees for 10 min. I
tried it, but it didn't work. Any suggestions?
If you actually did try that you must smack yourself in the head.
It's the actual material the CD-RW's are made of, not how you treat
them.
BTW why the hell did you post that here?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Seeker" <[EMAIL PROTECTED]>
Subject: Re: Re-using CD-R discs
Date: Tue, 22 Aug 2000 22:30:51 GMT
I don't think this will work, but they do taste great with a little soy
sauce.
"Sark" <[EMAIL PROTECTED]> wrote in message
news:39a2ec5c$0$62234$[EMAIL PROTECTED]...
> I have heard some rumours about being able to erase CD-R discs by baking
them in the oven. Someone said it was 220 degrees for 10 min. I tried it,
but it didn't work. Any suggestions?
>
> Sark
>
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.physics
Subject: Re: My unprovability madness.
Date: Tue, 22 Aug 2000 18:29:53 -0400
Denis,
I am holding the proof in my hand. I find your message
below astonishing. Maybe you could tell me what three
axioms the theorem depends upon. How can you say I didn't
the statement below?
> > > then the conclusion must be that _either_ you disagree with Godel's
> > > proof, _or_ that you believe that you can do without the ability to do
> > > arithmetic.
It isn't such a choice exclusively. I believe that the proof is
correct given its assumptions. I do not wish to do without
arithmetic. He said that I must chose between the opposites of
these two statements. Why do you think that I don't understand the
issues? Why don't you recognize his mistake?
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
On Wed, 23 Aug 2000, denis-feldmann wrote:
.
.
.
> > > then the conclusion must be that _either_ you disagree with Godel's
> > > proof, _or_ that you believe that you can do without the ability to do
> > > arithmetic.
> >
> >
> > This is not correct
>
> Arrogant ridicule, you say? (a little below)
>
> unless by arithmetic you mean to exclude finite
> > arithmetic, as in computers and other kinds of finite arithmetic and
> > arithmetic the integrates conditional processes. The axiom of
> > infinity is not the only axiom that might be thrown out to avoid
> > the theorem's conclusion,
>
>
> This is really interesting, but only goes to show your deep ignorance of the
> subject.
> Does the names of Tarski (or Chaitin) evoke something to you? Have you ever
> read any serious proof of Gödel theorem? Where on earth have you seen the
> axiom of infinity there (or in Peano axiom, or in the Principia you are so
> found (and so proud) of citing)?
>
>
> but those issues don't matter to me except
> > to point out that criticism of my statements have not been to the
> > point,
>
> I have not read the original statements, nor those criticisms, but judging
> from what you produce now, i wonder...
>
> but just arrogant ridicule.
> >
> > What do you want math for? Does everybody have to do it your way?
> >
>
> Strange way of not answering the question put to you, that is "_either_ you
> disagree with Godel's
> > > proof, _or_ that you believe that you can do without the ability to do
> > > arithmetic."
>
>
>
> >
> > > Perhaps, though, there was something additional which indicated that
> > > "I would want to use" applied to some specific purpose, such as
> > > cryptography, where a more restricted mathematical substrate would
> > > serve. Otherwise, I am hard put to think of what you could mean by
> > > 'selectively' quoted in this case.
> > >
> > > John Savard
> > > http://home.ecn.ab.ca/~jsavard/crypto.htm
> > >
> >
> >
> > Jim Trek
> > Future Beacon Technology
> > http://eznet.net/~progress
> > [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Comment from Hardware Experts Please
Date: Tue, 22 Aug 2000 22:58:31 GMT
My question is about performming a hardware multiplication in GF(2^n)
modulo an appropriate primitive polynomial. Sorry if my questions
seems vague, I am not a hardware expert.
Generally I have two questions:
1. Can it be done with relatively low amounts of hardware. I.e
cheaper unit. Low power as well.
2. Can it be done with a relatively high output rate. Relative to
what I am not sure, i.e can it be done quickly? Say something close to
nlog n steps?
I want to design a 128-bit block cipher using decorrelation in eight
rounds, this requires a 64-bit GF multiply which is very costly in
software. In hardware this cipher would require 1024 bits of SRAM but
this could be fed into the unit any way (i.e fed into latches in the
execution pipeline), and if the GF multiply is efficient in hardware
then the cipher could be practical for real usage.
Thanks,
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kryptos and Gillogly
Date: Tue, 22 Aug 2000 22:06:38 GMT
Achilles Outlaw wrote:
> And a side note to "Collomb"-- Come on, you can't be serious...
Alas, he seems to be serious, and persists in his belief
despite being informed that the sculptor and cryptographer
who created Kryptos confirmed the correctness of the other
(e.g., Gillogly) solution.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: 23 Aug 2000 00:19:43 +0200
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> Another way to consider the word length of a machine would be to see
> what alignment restrictions apply to instructions. This makes a
> System/360 a 16-bit machine, and even a Pentium an 8-bit machine;
> while this is an unambiguous convention, it doesn't say anything about
> the power of the machine or the underlying architecture, so it hasn't
> been used.
Using that as a criterion for the word length would have some weird
effects: it would make the 68000 and 68010 16-bit CPU's, while the
68020 and later would be 8-bit CPU's......
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Wed, 23 Aug 2000 00:22:55 +0100
Reply-To: [EMAIL PROTECTED]
On 22 Aug 2000 22:22:27 +0100, Bill Godfrey
<[EMAIL PROTECTED]> wrote:
>"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>
>> That is a tautology. The real question is, what is meant
>> by "X" in calling a computer an "X-bit machine"? I have
>> encountered real cases where no matter what you use for X,
>> it could be disputed.
>
>Which X is the most convienient to number of bits to fetch from
>memory at one time?
>
>Usually, it's the width of the data bus.
That rather depends on the architecture
a) having a fixed width bus and
b) having some sort of efficiency algo which depends on that width
this is all utterly OT here you know...
--
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Secret-sharing algorithm
Date: Tue, 22 Aug 2000 23:21:06 GMT
Hi,
Thanks to those who commented on my previous post. I'm trying to
design the beginning portion of my encryption algorithm where a client
and server both pass each other some random data to eventually create a
symmetric key. Please ignore the man-in-the-middle attack for now, I'm
going to implement authentication later.
1) Client requests server public key
2) Server sends public key
3) Client sends random data C1 encrypted using server's public key.
4) Server sends random data S1 encrypted using one-time pad, encrypted
with C1.
5) Both Server and Client generate symmetric key K1 using the
information C1 and S1.
Is this method secure? I know that the "one-time" pad isn't quite
really a one-time pad, but it's good enough, isn't it? Also, assume
that the random data will be around 40-64 bytes in length.
As a side note, I plan on expiring both the symmetric keys and the
server's public key every 1 hour or so.
Any glaring flaws?
Thanks,
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Kelsey Bjarnason" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Tue, 22 Aug 2000 23:33:20 GMT
[snips]
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kelsey Bjarnason wrote:
> > So, am I missing something?
>
> Yes -- through aliasing with array-of-(unsigned)-char,
> *all* of the representation of *any* object type is
> accessible.
Not as I read it, unless I haven't found that section yet. Specifically,
6.2.6.1#4 tells us that when copied to an array of unsigned char, the value
of an object will have _a_ representation; it doesn't say that this will be
unique.
Maybe I'm still missing it. I still can't, for the life of me, come up with
anything that _requires_ that char and byte actually be the same size
(bitwise), only that a char can fit in a byte.
> (This is guaranteed in the standard; the
> technical phrasing is that char does not have a "trap
> representation".)
Right - but an 8-bit char with no traps could handily fit inside a 17-bit
byte which itself _does_ have traps - just not ones representable within the
limits of a char.
> Thus there are no unused "padding"
> bits in the representation for type char.
No, nor was that the point; the point was that a _byte_ could have such,
even if a _char_ cannot; I have yet to see anything stating that this is
not, in fact, the case.
I know it's common to think of a byte and a char as synonymous in C... what
I can't find, from the standard, is any requirement that this is in fact the
case; the closest I come is that a char must fit in a byte. Beyond that, as
far as I can tell, all bets are off.
Now admittedly, from the C code's point of view, if a char were 8 bits with
no trap representations, but a byte were actually 17 bits and did have trap
representations, it should not matter - anything value you write to an
unsigned char would be valid. This is mainly a pedantic issue. :)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Secret-sharing algorithm
Date: Tue, 22 Aug 2000 23:29:06 GMT
In article <8nv1sg$muf$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi,
>
> Thanks to those who commented on my previous post. I'm trying to
> design the beginning portion of my encryption algorithm where a client
> and server both pass each other some random data to eventually create
a
> symmetric key. Please ignore the man-in-the-middle attack for now,
I'm
> going to implement authentication later.
>
> 1) Client requests server public key
Client should already have the key if this is a secured environment.
Or the key should be signed by another key already trusted.
> 2) Server sends public key
> 3) Client sends random data C1 encrypted using server's public key.
> 4) Server sends random data S1 encrypted using one-time pad, encrypted
> with C1.
> 5) Both Server and Client generate symmetric key K1 using the
> information C1 and S1.
Why not ditch 3-5 and just do this
3. Client sends server K1 which is encrypted using the servers public
key.
> Is this method secure? I know that the "one-time" pad isn't quite
> really a one-time pad, but it's good enough, isn't it? Also, assume
> that the random data will be around 40-64 bytes in length.
Why so much? Just use a 256 bit key encrypted with the PK crypto.
> As a side note, I plan on expiring both the symmetric keys and the
> server's public key every 1 hour or so.
>
> Any glaring flaws?
Ya, um making a key every hour could be a pain in the royal behind.
And the symmetric key should expire as soon as the communication is
finished, not every hour.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: What is required of "salt"?
Date: 22 Aug 2000 16:47:13 -0700
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> It just depends on the situation, doesn't it? Ideally, we want
> two-factor or better authentication: something you know, something
> you have, and something you are. Whether that kind of stuff is
> practical depends on how much money you have to spend on security,
> and how much you are protecting.
The fundamental problem is that today's password systems were built
under a threat model that is no longer relevant.
Today, if you send a password over the network in the clear, it *will*
be captured by eavesdroppers; if you force users to pick passwords, they
*will* pick low-entropy secrets. Neither of these realities matches well
with storing password hashes in a world-readable file or in requiring
passwords for network access to computer systems.
Once you figure out your threat model, you can talk about what is the
right technology. But my claim is that the threat model that passwords
were designed for is just so rarely seen today in computing that passwords
are typically the wrong tool for the job.
------------------------------
From: "Miki Watts" <[EMAIL PROTECTED]>
Subject: Questions about stream cipher
Date: Wed, 23 Aug 2000 03:13:33 +0200
Hi!
I've got a few questions about stream ciphers:
1. Are they faster (in general) than block ciphers?
2. Where can i find a list of (more or less) secure stream ciphers?
TIA
Miki Watts
------------------------------
From: [EMAIL PROTECTED] (Steve Leibel)
Crossposted-To: sci.math,sci.physics
Subject: Re: My unprovability madness.
Date: Tue, 22 Aug 2000 17:41:58 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Nathan the Great) wrote:
> On Mon, 21 Aug 2000 17:03:16 -0400, Future Beacon <[EMAIL PROTECTED]>
> wrote:
>
> >On 20 Aug 2000, Keith Ramsay wrote:
> >> Goedel was careful not to assume anything speculative in his proof.
> >
> >He was careful to specify the formal system Principia Mathematica
> >(PM). To characterize that system as not speculative is to simply
> >dismiss out of hand my suggestion that it may not be acceptable to
> >everybody.
>
> Principia Mathematica builds on Cantorian Set theory
Newton was dead and buried a hundred years before Cantor published.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Questions about stream cipher
Date: Wed, 23 Aug 2000 00:34:16 GMT
In article <[EMAIL PROTECTED]>,
"Miki Watts" <[EMAIL PROTECTED]> wrote:
> Hi!
> I've got a few questions about stream ciphers:
> 1. Are they faster (in general) than block ciphers?
Yes, but they can have their own disadvantages.
> 2. Where can i find a list of (more or less) secure stream ciphers?
SEAL from IBM and RC4 from RSADSI are the best so far.
The prob with stream ciphers is that you can't use the same key twice,
and in the case of RC4 random seeking is not possible in an encrypted
stream.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Tue, 22 Aug 2000 23:58:39 GMT
Shellac <[EMAIL PROTECTED]> wrote:
: Whatever, current physics certainly neither endorses, nor denies,
: determinism.
Indeed.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Tue, 22 Aug 2000 23:56:06 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: On Tue, 22 Aug 2000 00:06:33 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote: [snippety]
:>: Tim Tyler wrote:
:>:> It amuses me to think that some people feel they can completely dismiss
:>:> the idea that the universe is deterministic on the basis of our current
:>:> knowledge of physics.
: This isn't that "amusing", because there are good reasons to do so.
: Local hidden variable models have been eliminated by the EPR
: experiment.
: If one excludes exotic ideas like time-reversed wave propagation (and
: there are grounds for dismissing them as nonphysical) and assumes the
: speed of light to be an absolutely rigid limit (there appears to be an
: argument that one must do so to preserve causality), then we are
: constrained to admit that no 'underlying' theory can be true where the
: elements of the underlying theory all behave classically.
: Thus, a wave packet cannot really be a gas of thousands of discrete
: particles on some lower level if those particles are supposed to
: behave clasically, thus doing away with the strange behavior of the
: quantum particles they make up.
You appear to be arguing the same case as DAG.
Invoking randomness helps not one jot to get you out of this conundrum.
Even if events do not have predictable casuse, there's still weird
faster-than-the-speed-of-light, non-local happenings going on.
Given that things are apparently not classical in terms of locatity, what
does that tell us about thether a wholly finite, discreter, deterministic
model of the universe is possible?
It tells us nothing. It has no bearing on the issue. All it does is rule
out any local explanation - with or without randomness (given the
assumptions about the speed of light, etc).
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Wed, 23 Aug 2000 00:03:18 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> I hope this makes my intended meaning clear. If you are trying to draw
:> distinctions between these terms, it might help to explain what you think
:> the differences are, so that we are not at cross purposes over terminology.
: No, that would involve a very lengthy philosophic essay which is
: totally out of place (and which I am not inclined to write, since
: the issue is fairly standard and can be looked up in philosophy
: texts).
You object to my terminology, yet refuse to present your own.
Oh well - it doesn't seem very important. I hope I've written enough
to make my meaning abundantly clear, regardless of any terminological
quibbles about use of the word "determinism".
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED][Rot 13] (Eric Murray)
Subject: Re: Crypto Coprocessor on Javacard
Date: 22 Aug 2000 17:56:47 -0700
In article <[EMAIL PROTECTED]>,
Shawn Willden <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] writes:
>> I am interested to know if anyone has benchmarked Crypto Functions on a
>> Javacard with and without a crypto processor on the card...
>
>> 3DES encryption
>> 1024 RSA Key generation
>> etc
>
>> What type of speed improvement factors does one get , with the crypto
>> coprocessor.
>
>I don't know of any smart cards that have crypto coprocessors for DES
>operations, just RSA, so that part of your question is unanswerable.
GemPlus GPK4000 has DES and at least one mode of 3DES (2 keys, not three).
And RSA up to 1024 bits. It's been around for at least three years.
I don't remember the DES speed, other than "pretty slow".
>Similarly, RSA is only done on cards with coprocessors, so there isn't
>anything to compare. Most smart cards wouldn't even have enough RAM
>to hold the numbers, requiring that intermediate results be written to
>EEPROM (ugh!) if you tried to do RSA in software. Also, the
>processors are just too slow even if they had enough RAM.
>
>FYI, key generation times on smart cards are measured in minutes, even
>for 512-bit keys. Most smart card applications generate the keys
>off-card and inject them.
Also, most smartcards that have key generation have lousy RNGs.
There's a pretty tight limit on the power consumption specd
in 7816 (a common smartcard interface spec) and good RNGs
take a lot of power compared to memory cells.
> Private key operations (decryption and
>signing) generally take on the order of 10 seconds, public key
>operations (encryption and signature verification) take a second or
>so.
The GPK400 takes 1.4 seconds for verifying a 1024 bit RSA signature.
--
Eric Murray http://www.lne.com/ericm ericm at lne.com PGP keyid:E03F65E5
Security consulting: secure protocols, security reviews, standards, smartcards.
------------------------------
From: [EMAIL PROTECTED]
Subject: SSL protocol and unencrypted random info
Date: Wed, 23 Aug 2000 00:49:08 GMT
Hi,
I noticed that in the SSL 3 protocol, both the client and the server
send unencrypted random data to each other. This data, along with the
client-generated pre-master-key is used to generate the master key. The
pre-master-key is sent using the server's public key.
My question is why aren't the random data sent encrypted using the
server's public key? Doesn't this mean that the security of the
master-key is determined solely by the strength of the randomness of the
pre-master-key only?
The only reason I can think of is that the pre-master-key is large
enough such that it doesn't matter that the client and server random
data goes through cleartext. Perhaps this random data is used as a salt
so that it prevents replay attacks.
Am I on the right track?
Thanks
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Decryption
Date: Wed, 23 Aug 2000 00:54:33 GMT
On Tue, 22 Aug 2000 20:26:11 +0800, Herry Koh <[EMAIL PROTECTED]>
wrote, in part:
>Does anybody know
>any formal (or informal) methods (or tricks of the trade) of deriving
>the decryption algorithm from any general encryption algorithm (apart
>from the obvious method of working backwards, of course).
Well, there is nothing more tricky than that.
The inverse of f(g(h(x))) is invh(invg(invf(x))).
So if your steps are
XOR with subkey 1,
permute bits from 1 2 3 4 to 4 1 3 2,
XOR with subkey 2,
then to decipher you
XOR with subkey 2,
permute bits from 4 1 3 2 to 1 2 3 4
(and change the label on each bit to make that
from 1 2 3 4 to 2 4 3 1),
and XOR with subkey 1.
Maybe this worked example will help you to see whatever has caused you
problems.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
