Cryptography-Digest Digest #717, Volume #11 Sat, 6 May 00 13:13:01 EDT
Contents:
Re: GPS encryption turned off ([EMAIL PROTECTED])
Re: Increasing bit Entropy (Francois Grieu)
Re: Increasing bit Entropy (Francois Grieu)
Re: Fresco transmits my name (was: Spammed after just visiting a site) (Mark Wooding)
SBOX page (Tom St Denis)
Re: Crypto Export (David A Molnar)
SecureDoc 2.0-Does anyone have any experience with it? ([EMAIL PROTECTED])
Re: Crypto Export (Jerry Park)
Re: SecureDoc 2.0-Does anyone have any experience with it? (Tom St Denis)
Re: Increasing bit Entropy (Tim Tyler)
Re: Fresco transmits my name (was: Spammed after just visiting a site) (Greg
Hennessy)
Re: Any good attorneys? ("Trevor L. Jackson, III")
Re: Unbreakable Superencipherment Rounds (John Savard)
Re: GPS encryption turned off ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.geo.satellite-nav
Subject: Re: GPS encryption turned off
Date: Sat, 06 May 2000 13:20:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> Mxsmanic wrote:
>
> > "Martin Grossman" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> >
> > > SO, since the PLGR is considered not classified
> > > (I highly doubt this statement) ...
> >
> > If the device itself is classified, then anyone using it or coming
into
> > contact with it must have an appropriate clearance. That might
> > unacceptably restrict the number of people able to use the device
in the
> > field.
>
> Your right...I forgot about that!
>
> BUT......remember! there is a difference between....
> not classified and unclassified
>
> not classified means its never been reviewed by Dod
> and
> unclassified means its has been reviewed and has not been classified
> confidential/secret/top secret or it means it was classified at one
point
> in time and is now unclassified (available to the general public).
The DoD performs an extensive security review of PPS receivers. PLGRs
have passed the review and are considered Unclassified. Unlcassified
DOES NOT mean available to the general public. PLGRs are Unclassified,
but are not available to the general public
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Increasing bit Entropy
Date: Sat, 06 May 2000 15:46:18 +0200
RavingCow <[EMAIL PROTECTED]> wrote:
> If I have two streams of bits with a entropy of 0.5 bits / bit,
> how can I combine these to increase randomness ?
> Obviously, XOR would not be a good choice, but would
> addition mod. 2 work?
XOR indeed is addition mod 2.
> Would the entropy go up to 0.75, or would it be less ?
Assuming all bits are independant, the XOR of the bit streams
will have entropy
0.?135367285659782517112711.. bits / bit
Note: one digit intentionaly changed to ? in the above, to preserve
the interest of the exercice.
Hint: a bit stream of independant bits set with probability p
has entropy -p*lg2(p)-(1-p)*lg2(1-p)
Assuming both bitstreams are biased towards 0, the OR of the
bitstreams will have entropy
0.?375451476446613474988052.. bits / bit
where ? is the same digit as above.
Fun: design a combiner with memory that outputs at the same rate
as the OR above, but with entropy closer to 1.
More difficult: discuss what happens if the bitstreams are
correlated.
Francois Grieu
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Increasing bit Entropy
Date: Sat, 06 May 2000 15:56:01 +0200
RavingCow <[EMAIL PROTECTED]> wrote:
> If I have two streams of bits with a entropy of 0.5 bits / bit,
> how can I combine these to increase randomness ?
> Obviously, XOR would not be a good choice, but would
> addition mod. 2 work?
[earlier spoiler removed as per David Blackman's suggestion]
> Would the entropy go up to 0.75, or would it be less ?
Assuming all bits are independant, the XOR of the bit streams
will have entropy
0.?135367285659782517112711.. bits / bit
Note: one digit intentionaly changed to ? in the above, to preserve
the interest of the exercice.
Hint: a bit stream of independant bits set with probability p
has entropy -p*lg2(p)-(1-p)*lg2(1-p)
Assuming both bitstreams are biased towards 0, the OR of the
bitstreams will have entropy
0.?375451476446613474988052.. bits / bit
where ? is the same digit as above.
Fun: design a combiner with memory that outputs at the same rate
as the OR above, but with entropy closer to 1.
More difficult: discuss what happens if the bitstreams are
correlated.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Crossposted-To: comp.sys.acorn.misc
Subject: Re: Fresco transmits my name (was: Spammed after just visiting a site)
Date: 6 May 2000 14:05:33 GMT
[sci.crypt added to newsgroups.]
greg <[EMAIL PROTECTED]> wrote:
> "Rev. James Cort" <[EMAIL PROTECTED]> wrote:
>
> > I know this is off topic, but... speaking of which, the US government
> > changed its tune pretty quickly about that (128-bit SSL). Is it likely
> > that they've got a system which can cerack it?
>
> I personally think that they can.
Do you suspect this from a position of knowledge of cryptography, or are
you just responding with an uneducated personal guess?
Which of the following do you think are the weaknesses of 128-bit SSL3?
* The symmetric session keys are too short. A space of 2^{128} bits
can be searched in less than a week given the sort of computing
power available to the US government.
* The symmetric algorithms used by SSL3 are weak. The US government
is able to decrypt messages encrypted using all or most of 156-bit
triple DES[1], CAST-128, 128-bit RC2, and 128-bit RC4 in less than
a week.
* The US government can break RSA by factoring 1024-bit moduli in less
than a week because
-- they have enough computing power to make the generalized number
field sieve work fast enough; or
-- they have some clever new factoring algorithm which we don't
know about.
* The US government can break RSA because they can efficiently
decrypt messages without without factoring the RSA modulus, using
some method we don't know about.
* The US government have found a way of attacking the SSL3 protocol
itself, and have sufficient resources to mount an active attack
against every SSL connection crossing US borders (or a large
proportion of them, at any rate).
* The US government have persuaded all vendors of SSL3 software to
insert a back door for them in their implementations, although
nobody has noticed it. This includes the developers of OpenSSL,
who are based outside the United States and whose software is
released in source form and widely reviewed by experienced security
experts and cryptographers.
> This is how they have narrowed the recent Lovebug virus down to the
> servers at Manilla.
This is probably simple traffic analysis, which SSL doesn't attempt to
frustrate.
[1] Which has frustrated the concerted efforts of civilian
cryptographers worldwide for the best part of twenty years.
-- [mdw]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: SBOX page
Date: Sat, 06 May 2000 14:56:03 GMT
I am working on a SBOX design page where I am covering all the stuff I
have been teaching myself. If you want to read it (still not done) it's
at
http://www.tomstdenis.com/sbox.html
I would appreciate any comments/suggestions/etc...
Thanks,
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://tomstdenis.n3.net/search.html, it's entirely
free
and there are no advertisements.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Crypto Export
Date: 6 May 2000 14:33:58 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
> No, it is impossible. You can check tht it is sending out something
> which conforms to the protocol, but you cannot check that what is
> actually being sent out as encryption is what it claims to be. Only by
> examining the source and assuring yourself that the compiled corresponds
> to the source can you do so.
I'm not so sure about "impossible." At least in the academic setting,
there have been efforts to build protocols which are free of subliminal
channels. It means taking special care with the way the protocol is
designed, but the idea is to make something where the legitimate user
can say "if the messages this program sends out are conforming to
protocol, then I can do X and Y to rule out any info being
surreptitiously encoded in the message."
I agree that examining the source and making sure the binary corresponds
to exactly that and only that source is the best way to rule out evil
behavior. As you pointed out, though, some products aren't going
opensource any time soon. So I'm wondering if we can address that by
building better protocols, such that even if the program being verified
is a black box we can notice if it's doing something wrong.
We do seem to have one advantage -- since the legitimate user is trying
to verify his own program, we can say that the "verifier" has the
private key and output from the random number generator used in the
protocol.
Wait a second. How realistic is it to think that we can catch all the
sources of randomness used by a particular program? By this I mean that
all the random bits used by the program we're trying to verify can be
recorded and handed to the verifier. It seems that this would make the
verifier's job much easier.
> There was an article in sci crypt may years
> ago where a couple of people showed how in a public key system, the full
> private key could be encoded in the public key in such a way that it was
> impossible for anyone with the public and private keys to realise it.
> Ie, the public key contained the information in an encrypted form, which
> was easy for one who knew the encryption to decipher, but not for anyone
> else.
Yes, this is exactly what I'm worried about. I haven't seen the
sci.crypt message (I'll look for it in the archives). The other
example I know of is equally frightening -- GJ Simmons' 1979
observation that the Soviet silo monitors proposed for monitoring
compliance with the SALT treaty could be used to send subliminal
messages by picking from several ciphertexts to send.
story ref'd here :
http://ise.gmu.edu/~njohnson/Steganography/bib/3000077.htm
Another sobering report comes from CRYPTO '96, in which two researchers
actually built a version of PGP with a subliminal channel :
The Dark Side of "Black-Box" Cryptography, or: Should We Trust
Capstone?, Young, A. and Yung, M.
http://www.cs.columbia.edu/~ayoung/crypto96.ps
(see the rest of Adam Young's papers for more fun things to do with back
doors)
There seems to be some work on creating "subliminal-free" protocols.
One page on the subject is due to Yvo Desmedt, and is here :
http://www.cs.fsu.edu/~desmedt/topics-subliminal.html
There was also a recent Journal of Cryptology article on the subject,
which I still don't understand at all. :-\
What I want to know
* are practical verifiably subliminal-free versions of our
favorite protocols possible?
* are these versions efficient?
* can they be realized on a real PC, and what kinds of
assumptions do they need (e.g. does "private randomness"
break a verification protocol which needs to see all the
random choices made by the program?)
* MOST IMPORTANTLY -- what would *you* be willing to believe as
evidence that the program isn't leaking data? how much trouble
would you be willing to go to in order to verify this?
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: SecureDoc 2.0-Does anyone have any experience with it?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 06 May 2000 15:57:24 GMT
My apologies if this is not the proper newsgroups to ask this question
on.
Recently, Smart Computing magazine published a volume in its Learning
series about privacy, and in the encryption chapter, it was reviewing
programs encryption programs, and one was called SecureDoc. It
supposedly encrypts the operating system as well, and uses a password,
and I guess a key you place on a floppy.
The reason I am asking about this program, I was thinking of
purchasing it, because I travel, and am doing some things right now
that requite me to have a laptop. I have to provide my own laptop
security program, if I want things to stay secure. And, I am carrying
personal information on this( checking info and stuff) that i don't
want to get into the wrong hands.
I though about just using Scramdisk, but the thing about
scramdisk, is that it is till possible for someone to install a
keyboard monitoring program, and let it run in the background, in
order to retrieve your password. I don't think you can do this with
SecureDoc. But, At $100, its not a program I'm just going to buy
without checking it out with knowledgeable sources( you all).
Heck, If I could just get some advice about keeping info
secure on a laptop, I would be appreciated.
Thanx, all. FJ
------------------------------
From: Jerry Park <[EMAIL PROTECTED]>
Subject: Re: Crypto Export
Date: Sat, 06 May 2000 11:03:35 -0500
Adam Durana wrote:
> > I don't think you will find any arguments which make any sense (I've never
> seen
> > a sensible argument for it).
>
> Actually there is a sensible argument and you have most likely heard it, but
> you didn't like it. As long as the US puts limits on the export of
> technologies that use strong cryptographic algorithms there is no way some
> sort of basic communications standard will evolve that incorporates strong
> crypto. Sure you might say there are already many standards that involve
> strong crypto, but there is still a great deal of communications that go on
> around the world that don't use strong crypto or any encryption at all.
> From the standpoint of the agencies, such as the NSA and CIA, that monitor
> communications around the world, this situation is ideal. Now if there was
> no limits on the export of crypto, eventually every method of communication
> would be encrypted in some form. And this would make those agencies' job's
> a lot harder.
>
> I'm sure you've heard this claim before, and it does make sense. I am not
> saying its good or bad, but it does make sense.
>
> - Adam
No. It only means that American citizens will not develop and deploy those
technologies. It makes no sense for a government to harm its own people.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SecureDoc 2.0-Does anyone have any experience with it?
Date: Sat, 06 May 2000 16:16:47 GMT
[EMAIL PROTECTED] wrote:
>
> My apologies if this is not the proper newsgroups to ask this question
> on.
> Recently, Smart Computing magazine published a volume in its Learning
> series about privacy, and in the encryption chapter, it was reviewing
> programs encryption programs, and one was called SecureDoc. It
> supposedly encrypts the operating system as well, and uses a password,
> and I guess a key you place on a floppy.
> The reason I am asking about this program, I was thinking of
> purchasing it, because I travel, and am doing some things right now
> that requite me to have a laptop. I have to provide my own laptop
> security program, if I want things to stay secure. And, I am carrying
> personal information on this( checking info and stuff) that i don't
> want to get into the wrong hands.
> I though about just using Scramdisk, but the thing about
> scramdisk, is that it is till possible for someone to install a
> keyboard monitoring program, and let it run in the background, in
> order to retrieve your password. I don't think you can do this with
> SecureDoc. But, At $100, its not a program I'm just going to buy
> without checking it out with knowledgeable sources( you all).
> Heck, If I could just get some advice about keeping info
> secure on a laptop, I would be appreciated.
> Thanx, all. FJ
At $100 you can ignore it. Just get PGPi from http://www.pgpi.com, it's
free and well respected.
Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Increasing bit Entropy
Reply-To: [EMAIL PROTECTED]
Date: Sat, 6 May 2000 15:55:16 GMT
RavingCow <[EMAIL PROTECTED]> wrote:
: If I have two streams of bits with a entropy of 0.5 bits / bit, how can
: I combine these to increase randomness? Obviously, XOR would not be a
: good choice, but would addition mod. 2 work? Would the entropy go up to
: 0.75, or would it be less?
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Increasing bit Entropy
Newsgroups: sci.crypt
References: <[EMAIL PROTECTED]>
Organization:
Reply-To: [EMAIL PROTECTED]
RavingCow <[EMAIL PROTECTED]> wrote:
: If I have two streams of bits with a entropy of 0.5 bits / bit, how can
: I combine these to increase randomness?
Feed them into a hash.
: Obviously, XOR would not be a good choice, but would addition mod. 2 work?
Addition mod. 2 *is* XOR ;-)
: Would the entropy go up to 0.75, or would it be less?
With XOR 0.75 sounds like a very reasonable figure - if the streams are
independent.
With a hash you should be able to do *much* better...
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: Greg Hennessy <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.acorn.misc
Subject: Re: Fresco transmits my name (was: Spammed after just visiting a site)
Date: Sat, 06 May 2000 17:43:53 +0100
On 6 May 2000 14:05:33 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote:
>[sci.crypt added to newsgroups.]
>
>greg <[EMAIL PROTECTED]> wrote:
>> "Rev. James Cort" <[EMAIL PROTECTED]> wrote:
>>
>> > I know this is off topic, but... speaking of which, the US government
>> > changed its tune pretty quickly about that (128-bit SSL). Is it likely
>> > that they've got a system which can cerack it?
>>
>> I personally think that they can.
>
>Do you suspect this from a position of knowledge of cryptography, or are
>you just responding with an uneducated personal guess?
Given the pathetic level of knowledge in his prior postings. One can
only speculate.
> -- they have some clever new factoring algorithm which we don't
> know about.
That may be a possibility. A algoritmic gem like that would have the
levels of secrecy above & beyond for example the manhattan project.
> * The US government have found a way of attacking the SSL3 protocol
> itself, and have sufficient resources to mount an active attack
> against every SSL connection crossing US borders (or a large
> proportion of them, at any rate).
I would just love to see the kit that could do that, especially in
anything approaching a real-time context.
greg
------------------------------
Date: Sat, 06 May 2000 12:57:19 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Joaquim Southby wrote:
> In article <[EMAIL PROTECTED]> Trevor L. Jackson,
> [EMAIL PROTECTED] writes:
> >Copyrighted software has a different set of concerns than patented software.
> >With copyrights, it is the act of copying that is restricted. With patents, it
> >is the act of usage that is restricted.
> >
> I can copy material (i.e., "the act of copying") all day long with no
> penalty if it's for my own use. With software, that's called a backup.
> However, if I redistribute that copied material without permission of the
> copyright holder, I am in violation of the copyright laws.
>
> I'm not certain what you mean by "the act of usage". Part of your
> previous post alluded to a system in which each user is responsible for
> determining if patent law is pertinent for their case. Are you saying
> that if I incorporate some patented object into a product and distribute
> it, the user is liable under patent law and not me?
It depends on the jurisdictional boundaries that are crossed. If A manufactures a
device in a jurisdiction (J1) where it is legal to do so and sells the device
(distributes it) to B, and B imports it into a jurisdiction (J2) where it infringes
upon a patent and uses it, then A has not infringed the patent, but B has. If the
sale from A->B happens within the J2, then AFAIK, A has infringed the patent. Note
that even though A was the original infringer in the second example, B's use of the
patented device within J2 is also an infringement that the patent holder can enjoin.
>
>
> >This is why using the international version of PGP is illegal inside the US. It
> >is not illegal to own, or even copy international PGP inside the US. But it is
> >illegal to use it.
> >
> I don't think you want to be using PGP as an example in this argument. I
> just looked at the disclaimer page at Network Associates
> (http://www.pgpinternational.com/legal/) and there is nothing on that
> page about restricting PGP usage because of patent concerns.
> The issues
> they are trying to deal with are US export regulations. AFAIK, the only
> patent involved in PGP is the RSA key generation which is not included in
> the freeware versions. I also looked at the registration pages for both
> the freeware international PGP and the commercial international demo and
> neither page mentions anything like you stated. The list of countries on
> the pull down menu includes Guam, American Samoa, US Virgin Islands, etc.
> -- all of which are subject to US patent law. Which statutes do you
> believe are being violated if someone uses the international version
> within the US
In the quote above I used the present tense which was a mistake. I believe the
situation has changed in that there is now a library used in PGP that does not
violate the RSA patents. That opinion is weak because I have not tracked the details
recently. On firmer ground, there was a version (?2.6) that existed in US and
international flavors. The US flavor did not infringe the RSA patents, but I think
it's export was restricted. The international flavor did infringe the RSA patents,
but only if used within the US. So an international traveler was supposed to use 2.6
inside the US and 2.6i outside the US, which required an uninstall/reinstall at each
crossing of a US border. Har.
>
> >Thus I believe your conclusion is flawed by the application of copyright
> >principles to the domain of patents. You may want to reread the portion of my
> >post that you snipped.
> >
> You are right. I shouldn't have used illegal downloads of copyrighted
> software as an example. The portion of your post you refer to is not
> relevant to my argument since I don't believe the end user is liable or
> responsible for a patent violation in a product they received from
> someone else. I'll have to run that one by the patent lawyers at my
> company next week for their opinion.
I'll be interested in the opinion. In the past users have been enjoined from using
patented technology even though they were not the "manufacturer" or "distributor".
In the absence of this consideration, would-be violators could set up dummy
companies, manufacture the rip-off products for themselves, and be immune to the
consequences of enforcement of the patent upon the dummy. Consider, for example,
patents that are never licensed, but used to distinguish a company from its
competitors.
> In any case, you seemed to be taking issue with my usage of the term
> "distribution" even though I was trying to agree with you in the first
> place that there could be dispute about that term.
Mostly because it is hard to analyze products as slippery as freeware. Since there's
no money involves the author has no knowledge of the users, and may not have any form
of contact with the majority of the users because there can be an arbitrarily large
number of intermediaries who copy the software (with the blanket permission of the
author), and who might be better characterized as "the distributor".
> I was trying to
> illustrate that point with my reference to copyrighted software on a
> Hotline server. Let's change that to "software containing patented
> algorithms". Do you believe that anyone should be able to use a patented
> algorithm in a piece of software and either sell it, give it away, or
> make it available for download without compensating the holder of the
> patent?
AFAIK, compensation to the holder of the patent is not relevant. Permission is
relevant. (Of course permission may require compensation ;-)
Your question does not address the issue of multiple patent jurisdictions. Within a
single jurisdiction, one cannot legally sell, give away, or make available for
download any patented product/technology/algorithm. Nor can one use it without the
patent holder's permission.
Can anyone not in the jurisdiction of a patent sell a piece of software that would
infringe if sold within the patent jurisdiction? Yes. Can one give it away? Yes.
Can one make it available for the download? Yes. The third point is the only sticky
one. I reached the affirmative conclusion by reasoning that forbidding the
downloading of the software would prohibit legitimate activity, which rules out the
blanket prohibition on downloading software. In support of this we can observe that
the person who moves the software from outside the patent jurisdiction to within the
patent jurisdiction is the one responsible for the infringement. That action,
"infringing distribution" if you will, is the action that is prohibited by the
existence of the patent.
A logical extension of this line of reasoning leads to the conclusion that while one
cannot sell or give away patented technology within the patent jurisdiction, one
could make it available for download. If we presume that the software is offered
with the proviso that users within the jurisdiction would have to seek the permission
of the patent holder then in theory there is no infringement. I suspect this
conclusion is far out on thin ice.
An interesting question is the possibility of downloading from a site within the
patent jurisdiction to a site outside the patent jurisdiction. I don't know whether
this counts as infringement.
I think the analogous actions of sale from within to a buyer outside or gift from
inside to outside might be considered infringement. After all, the seller/giver is
benefiting in some way from the IP of the patent holder.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Unbreakable Superencipherment Rounds
Date: Sat, 06 May 2000 16:37:33 GMT
On 06 May 2000 01:46:48 GMT, [EMAIL PROTECTED] (UBCHI2) wrote, in
part:
>There is a way to encrypt communications that make them impregnable to
>cryptanalysts theoretically. Can the following sequence be implemented?
>1) 1 round RC6
>2) 1 round TwoFish
>3) 1 round Serpent
>4) 1 round Mars
>5) 1 round Rijndael
The 3DES will probably provide more security than only five rounds,
even if they are mixed. Also, using one round of each, rather than
_two_ rounds of each could introduce some weaknesses. Otherwise, this
is a very good idea, in my opinion, because I think in the same
general way when it comes to thinking of how to attain very high
security.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
Date: Sat, 06 May 2000 13:11:24 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: GPS encryption turned off
Paul Schlyter wrote:
>
> Also: many GPS receivers (including my own Garmin 12XL) seem to try
> to solve for longitude and latitude more accurately than for altitude.
I suspect this is because most of us live in the flat parts of the world. If
the receivers had been designed in Nepal, where every morning the 10-year-old
girl climbs down 3000 feet of mountain, fills a bucket of water, and brings it
back for breakfast, the receivers would concentrate on altitude ;-)
------------------------------
** 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
******************************
