Cryptography-Digest Digest #726, Volume #9 Wed, 16 Jun 99 07:13:03 EDT
Contents:
Re: Generating Random Numbers (Herman Rubin)
Re: Secret info for MACS (David P Jablon)
Re: DES (Jerry Coffin)
signal to noise ratio
Re: Message for DSCOTT(was:SLIDE ATTACK FAILS) (Boris Kazak)
Peer review request ("almis")
Re: Cryptonomicon Errata in Neal Stephenson's new fiction: (wtshaw)
Re: encrypt using ASCII 33 to 126 only? ([EMAIL PROTECTED])
Re: Algorithm from easy spec please! (wtshaw)
Test arrays for GOST 28149-89 ("Serge")
Re: stream ciphers (John Savard)
Kryptos article (Jim Gillogly)
Re: Secret info for MACS
Re: [Q]: Session key exchange (Jyrki O Saarinen)
Re: signal to noise ratio (Horst Ossifrage)
Re: Algorithm from easy spec please! ("Kenneth N Macpherson")
Re: Algorithm from easy spec please! ("Kenneth N Macpherson")
Re: OTP is it really ugly to use or not? (Dave Hazelwood)
Re: DES lifetime (was: being burnt by the NSA) ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Generating Random Numbers
Date: 15 Jun 1999 19:23:54 -0500
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Herman Rubin wrote:
>> For any purpose, I would recommend a seed in the thousands of bits
>> at least if a semblance of randomness is to be attained.
>It depends on the "generator". Some stream systems are pretty
>strong (i.e. nobody outside the IC seems to know how to break
>them) with keys ("seeds") around 100 bits.
There are often weaknesses even if nobody knows how to break
them. This is especially true for statistical purposes, where
a complicated subtle bias can give bad results, while the
cryptographic information is too low to be useful.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Secret info for MACS
Date: Tue, 15 Jun 1999 23:45:58 GMT
In article <[EMAIL PROTECTED]>,
Casey Sybrandy <[EMAIL PROTECTED]> wrote:
>This may be a dumb question, but can the hash of a person's password be
>a good piece of secret info for a MAC?
Not so dumb. There are plenty of protocols that do this.
But it's still a bad idea, since it fails for low-entropy
passwords.
Password-authenticated key exchange protocols negotiate a
large-entropy MAC key from a (potentially) low entropy password.
See http://www.integritysciences.com/speke.html for an example.
-- dpj
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: DES
Date: Tue, 15 Jun 1999 19:06:23 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> The IP is applied to the data rather than to the key.
OOps -- right. I'm not sure what I was thinking when I wrote that,
but it was obviously nonsensical.
------------------------------
From: <[EMAIL PROTECTED]>
Subject: signal to noise ratio
Date: Wed, 16 Jun 1999 01:05:48 GMT
In Differential Cryptanalsis,
What is the signal to noise ratio?
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Message for DSCOTT(was:SLIDE ATTACK FAILS)
Date: Tue, 15 Jun 1999 19:03:14 -0400
Reply-To: [EMAIL PROTECTED]
Matthew Faupel wrote:
>
> Boris Kazak <[EMAIL PROTECTED]> wrote:
>
> > This message is for David Scott.
> > This message is intentionally left unencrypted.
> >
> > �� ������ ����� ������,
> > ��� �����, ������� -
> > ��������, ��� ����� � ��������� � ��� -
> > ��� �� ������ ����� ����� ������.
> >
> > ������ �� ��������, ��������� ������ ��.
> > �������� �����, �� �� ���� ��������,
> > � �����. � �������, � ������� -
> > �� ��� � ����� � ����� � ���!
> >
> > "�������, ��������� ��������� -
> > �� ����� ������� - ���� �� � ������ ��������?
> > ������, �� �� �������, � �� ���� �ģ� ���ң�
> > � ��� ������ ������ �� ���������" -
> >
> > "��, �� - �� ������ �������� -
> > ��� ��-�� ��� � ���� �������,
> > ��� � ������ ��� �����
> > ���� ������� � ������� �������.
> > ������ �� ������� ������ -
> > "�� ������, ����� ��� ������,
> > ��� ���� �� �����"
> >
> > I hope you will have no problems reading this. BNK
>
> So, does that make Bruce an Elephant then?
===================
Most certainly (don't tell him this), but the important thing is
what analogy do you find for his opponent...
------------------------------
From: "almis" <[EMAIL PROTECTED]>
Subject: Peer review request
Date: Tue, 15 Jun 1999 22:41:17 -0500
A few months ago I quietly presented an application that I wrote
called Cryptic 4.0 . (only one post)
Judging from the posts I have read on this newsgroup, perhaps I was too
quiet.
The few responses I did receive held a mixed message.
Evidently the documentation is a 'hard read'. (Although I didn't think so
when I wrote it.)
However; you will need some math when reading the
topics on 'rotor indexing' or 'the mathematics of a rotor machine'.
So far only one error has been reported. And that, a typo, in
a calculation in the documentation which has since been corrected.
Since much of the math was learned 'as necessary' dictated by the
needs of the project, there are, doubtlessly, many more
corrections that need to be made.
Hence I again request a peer review.
The application can be found at http://ww2.netnitco.net/users/almis
The application (the only file there) is Cryptic4.zip
All executables, source code and documentation are included.
The program is a 'Rotor Machine' that runs in Windows or
command prompt mode.
Use is made of the Win32 API and is, thus, restricted to NT4 or
Win95 or Win98 and presumably (unless Microsoft is lying) NT2000.
All docs are Word 97 (Word 6).
As an incentive I have written and included in the \Utilities subdirectory
of the
zip file a small, stand-alone program that implements Ueli Maurer's
'Universal Statistical Test for Random Bit Generators' which, the author
claims,
is superior to most statistical tests in that it measures '... the per-bit
entropy
of a source'. (Written in ANSI C and should compile for any platform)
Finally; should you decide to review this application take a look at:
http://www.enigma-co.com
This outfit has a program called 'Ultra Enigma'.
See if it is essentially the same as my application.
There are differences. The use from 3 to 8 rotors (they call them wheels)
while my program allows from 0 to 256.
Their help file cautions on the need to be careful with the order of
encrypted and decrypted files... See if the 'composite pointer' in my
program
is a secure solution to their synchronization problem.
They allow for variable stepping of the rotors. See, in the mathematics
topic,
that if the stepping is relatively prime to the rotor length then the
coefficient matrix
does not change. And if the stepping is not relatively prime, then the rotor
may be replaced with one that is shorter and, presumably, easier to solve.
There are other differences: The price for their product is $150 while
mine is $0.
Differences aside, we are obviously allies in that we both feel that
the rotor machine is an excellent cryptographic engine.
...al
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cryptonomicon Errata in Neal Stephenson's new fiction:
Date: Tue, 15 Jun 1999 21:09:12 -0600
In article <[EMAIL PROTECTED]>, C T Skinner
<[EMAIL PROTECTED]> wrote:
> Cryptonomicon Errata
> Neal Stephenson's new fiction:
>
> I am up to p215 & have noted these errata:
> p54 Factoring is not 2x as hard with each extra bit,
> more like sqrt(N log N) or whatever NFS is these days
> p70 2nd line of decrypt T should be R
> p92?? earthquake damage in Manila in the 80's (this may well be true, or
> true fiction, Volcanoes,Typhoons, I may have forgotten the odd
> earthquake)
> p98 "sicks out" should be "sticks out"
Speaking of sticking, I'm almost certain that peel-off sticky surfaces
were not around in WWII.
There are some typos here and there, and some technical statements that
might be interesting to debate, but the self-appointed license to weave
history and yarn was well chosen.
>
> Do yourself a favour and get this book
> (I have not got very far, obviously, and one reviewer said that
> NS doesnt tidy up his plot lines, but so far it is delightful.
I agree. Don't plan to read it at one sitting.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 15:50:05 GMT
In article <[EMAIL PROTECTED]>,
"Kenneth N Macpherson" <[EMAIL PROTECTED]> wrote:
> A damn good idea. I will try this.
I do my best.
> >Why not binhex/uuencode the encrypted 8 bit chars?
Convert the binary output to hexadecimal. That way the only chars in
are 0-9 and A-F but you can encode any byte.
> Now there is a question - I have an RC4 dll which will encode using
> "keyboard" chars only but I am not sure if I can use it commercially
or
> not - can someone set me straight?
It's really belongs to RSADSI but there is no copyright/patent.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Algorithm from easy spec please!
Date: Tue, 15 Jun 1999 22:09:31 -0600
In article <[EMAIL PROTECTED]>, "Kenneth
N Macpherson" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> If someone knows of a way to do this I would be grateful!
>
> Need to take the numbers 32 to 126 inclusive and insert them into an array
> randomly based on a key (of numbers).
>
> The numbers in the key will all be in the range 32 to 126.
>
> It is a simple lookup table.
>
> Pseudo code would be brilliant and vb code would be fantastic!
>
> Thanks in advance,
>
> Cheers,
>
> Ken
Talking of keyboards, someone posted a simple system with the
you-can't-solve-it tag in which keys adjacent of the plaintext keys were
pressed in a pattern. Taking the basic idea, I implemented and added to
it.
Figure the you have 47 keys, and have two cases for each. If you allow the
case and spaces to pass through, you do leak some of the plaintext, but
still have an interesting result. For this example, I use an 47 character
alphabet taken directly from the keyboard, left to right, top to bottom.
The key is composed of a single reference character followed by other
characters; convert this to a series of offsets. My key can be from 2 to
47 characters.
Encrypt by finding the plaintext character, adding the current offset, and
getting the ciphertext characters. Simple enough?
This sentence is the key. The above couple of lines are simply encrypted
to be what follows. Notice that each time a T, the reference character,
is repeated in the key, the plaintext and ciphertext characters are the
same. Naturally, 47 keys would produce the same encryption since any of
the 47 could be the reference character.
F.2ar`t cm 4y.xi9d kfr $1fg5evxe t6]u'chqjn s)n[5v e9e z,xwy5t ;s.\r?- f5x
dvte.td ibe 6yxfr>hy1s z9aw4weyas= |'b[Rf y5ht8h<
This is really just based on a simple slide cipher. My version does other
sized alphabets as well, 26, 30, 40, 47, so the sourcecode reflects that.
I did not mess with random deranged alphabets or keys, but those could be
a additional complication.
The FutureBasic Sourcecode probably would not be too helpful to you, about
15K in the single textfile which yields a fully implemented GUI
application for a 68K Mac. The big trick in functional crypto is to get a
shell for programs that works for you on your platform with a simple
algorithm, then modify. Once the simple things like this algorithm are
shown to work, you can get into more complicated ones.
--
More is less.
------------------------------
From: "Serge" <[EMAIL PROTECTED]>
Subject: Test arrays for GOST 28149-89
Date: Wed, 16 Jun 1999 08:40:17 +0400
Can someone post or send email test arrays for russian cryptographic
algorithm GOST 28149-89 (also known as simply "GOST")?
Regards,
Serge.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: stream ciphers
Date: Mon, 14 Jun 1999 16:52:13 GMT
[EMAIL PROTECTED] (James Pate Williams, Jr.) wrote, in part:
>If you are a citizen of the United States of America, currently
>residing in the U.S.,
Not unless Poland has become the 51st State... I think you forgot to
peek at the E-mail address in the post to which you're responding.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Kryptos article
Date: Tue, 15 Jun 1999 22:09:09 -0700
John Markoff has written an article at the NY Times site about
the Kryptos sculpture: www.nytimes.com in the Technology section.
You might enjoy using the known plaintext there to see how the
three ciphers that I decrypted were constructed. Note that the
third cryptogram's plaintext should have a "Q" added at the end
before the question mark. I was interested when I called the
CIA Public Affairs office last week to learn that it had previously
been partly solved inside the intelligence community.
Neither I nor the other solvers (a team of three NSA cryppies
and a non-cryptographer CIA analyst, working separately) have
yet been able to solve the last 97 characters:
OBKR
UOXOGHULBSOLIFBBWFLRVQQPRNGKSSO
TWTQSJQSSEKZZWATJKLUDIAWINFBNYP
VTTMZFPKWGDKZXTJCDIGKUHUAUEKCAR
There aren't many repeats of note, and if there's any periodicity
it's pretty grotesque (i.e. period 25). I suspect running key,
or perhaps a combination polyalphabetic substitution and permutation,
or perhaps an autokey of some sort. I think it is keyed rather than
a OTP because in one of the old articles Sanborn, the sculptor, says
the mysterious envelope delivered to the Director of Central Intelligence
contains the keys to the sculpture, and that with those the DCI could
decrypt it easily.
--
Jim Gillogly
26 Forelithe S.R. 1999, 05:07
12.19.6.5.1, 5 Imix 9 Zotz, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Secret info for MACS
Date: 16 Jun 99 05:15:58 GMT
Casey Sybrandy ([EMAIL PROTECTED]) wrote:
: This may be a dumb question, but can the hash of a person's password be
: a good piece of secret info for a MAC?
It certainly _can_ be, in principle. However, it isn't safe to use the
hash that's stored in the password file, even if it is a "shadow password"
file, hence protected by the operating system. The level of protection an
operating system can give is much weaker than that which cryptography at
least appears to give.
If you do something like this:
User password -- hash1 -- hash2 --> result sent over communications link
to sign on
with the user password *never* transmitted in the clear (i.e., something
like Kerberos is in use) and even hash1 of it is *never* transmitted,
and the shadow password file stores this:
User password -- hash1 -- encryption --> entry in shadow password file
*then* hash1 of the user password is indeed a shared secret. Since it's a
small one, and users do choose poor passwords, probably it should be used
with a technique like EKE (which, unfortunately, is patented) to obtain a
more usable shared secret.
John Savard
------------------------------
From: Jyrki O Saarinen <[EMAIL PROTECTED]>
Subject: Re: [Q]: Session key exchange
Date: 16 Jun 1999 06:06:48 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
: I'm not familiar with the H8/S and don't know what a "simple
: operation" is on it. The operation that matters is integer multiplication.
: Unless the H8/S has a parallel multiplier (doubtful) or a DSP extension,
: multiplication will take much more than 2 cycles.
Multiplication is around 20 cycles for a 16x16 -> 32 mul.
: I think the 68030, which is basically a 32-bit cpu, will be far
: more than 2-3x faster, especially for this. More like 10x-100x.
H8/S is a also a 32-bit CPU internally with a 16-bit data bus.
68030 executes simple register instructions (move, add etc.)
in 2 cycles when in instruction cache, as does the H8/S.
So, estimating 2-3x faster for a 030/20 vs. H8S/10 isn't that
far off IMHO.
: If you have to use public key and one end of the connection has a fast
: cpu (e. g. a Pentium or something), you could do RSA.
Some mechanism of having different key for each session is needed,
since a fixed secret key in both ends is next to nothing.
: I'm skeptical that you need public key methods at all. If you
: describe your application in more detail I may be able to make
: other suggestions.
A H8/S based device comminicating through TCP quite frequently,
requesting information from the PC server, and telling the server to
perform potentially dangerous events. So, the requirements are:
- confidentality, the information in some messages might benefit
listeners
- autethication, the server must be sure the commands it was sent,
where from a legal source
------------------------------
From: Horst Ossifrage <[EMAIL PROTECTED]>
Subject: Re: signal to noise ratio
Date: Wed, 16 Jun 1999 01:34:08 -1000
[EMAIL PROTECTED] wrote:
>
> In Differential Cryptanalsis,
> What is the signal to noise ratio?
The phrase "signal to noise ratio" is not used for technical
accuracy, it is a metaphore. It describes the different
probabilities that a differential occurs compared to other
differentials.
Given a known S-Box, one may list all possible inputs,
all possible outputs, and then list all possible XORs of
two inputs and the resulting XORs of the output pairs.
It is possible that all XORs of pairs of inputs and outputs
occur with equal frequency (zero s/n ratio). But many
S-Boxes have certain XOR pairs of outputs that never occur
or occur with high frequency (high s/n ratio).
s/n ratio is a short phrase to communicate the flavor
of that situation. There is no noise, technically speaking.
------------------------------
From: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Re: Algorithm from easy spec please!
Date: Wed, 16 Jun 1999 09:07:21 +0100
Thanks for all of the suggestions - here are some additional comments.
The key will be 14 chars long and may contain duplicates but all will be in
range 32 to 126.
I like the random number swapping idea using the key to seed the generator
but, will seed X on machine A produce the same random sequence as seed X on
machine B?
Thanks,
Ken
------------------------------
From: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Re: Algorithm from easy spec please!
Date: Wed, 16 Jun 1999 09:15:42 +0100
A method of scrambling the consecutive numbers using the key but not using
pseudo random sequence would be good as I am not sure that 2 different
machines will produce the same sequence when seeded with the same key.
Ken
------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: OTP is it really ugly to use or not?
Date: Wed, 16 Jun 1999 09:55:53 GMT
[EMAIL PROTECTED] (Mickey McInnis) wrote:
>g.chips.and.spam.com> <7k1k2d$brj$[EMAIL PROTECTED]>
><[EMAIL PROTECTED]>
>Organization:
>Keywords:
>
>In article <[EMAIL PROTECTED]>, fungus
><[EMAIL PROTECTED]> writes:
>|>
>|>
>|> [EMAIL PROTECTED] wrote:
>|> >
>|> > I will send you a OTP message and you will never solve it :)
>|> >
>|>
>|> Sure I will. I'll just go roud to your house and start
>|> snipping little pieces off you and put aftershave in the
>|> holes. The message will soon be compromised...
>|>
>|>
>|>
>|>
>|> --
>|> <\___/>
>|> / O O \
>|> \_____/ FTB.
>
>
>That's actually one of the nice things about OTP's. He can give
>you a false OTP "key" that decrypts his ciphertext into a different
>plausable but wrong cleartext. You never know whether or not he
>sent a different "real" cleartext with a different "real" key.
Yup. I love it.
>With proper preparation, OTP's can be used for "rubber hose resistant"
>cryptography. Even someone who doesn't know the cleartext or key
>can make up plausable but wrong cleartext/key/ciphertext combinations.
Yes, I can make up as many combinations as there are possible messages
of that length. To do this you just make up a new cleartext message of
the same length and xor it with the ciphertext and you get a new key
for the new message for the same ciphertext.
>
>That's also one of the benefits of using "truly random" number generators
>vs. some sort of pseudorandom number generator. You probably can't use a
>PRNG to come up with a key that matches a chosen cleartext to a
>chosen ciphertext.
I don't understand the last sentence. Who needs a PRNG, just xor the
cleartext with the ciphertext and you have the key?
For a chosen cleartext and a chosen key there is only ONE ciphertext
For a chosen cleartext and a chosen ciphertext there is only ONE key.
For a chosen key and a chosen ciphertext there is only ONE cleartext
Cleartext = A or 41
Key = 08
cleartext xor key = ciphertext 41 xor 08 = 49
cleartext xor ciphertext = key 41 xor 49 = 08
key xor ciphertext = cleartext 08 xor 49 = 41
In the above case my message was the character A
and the key was 08 yielding a ciphertext of 49.
Now if you are trying to crack my message there
are 256 equally possible keys (00 to FF) that can be
xor'd with 49 and each will will yield a unique message
out of the possible 256 messages. It is impossible to
know or calculate which is the correct one.
I don't think it matters much at all whether the pad is
truely random either. As long as you do not reuse a pad
it seems to me that you have top notch protection. Using
random numbers of course gives you mathmatical proof
of unbreakability but I am not sure that using almost
random numbers makes it any less secure except for not
being able to do the "proof".
In fact I think it may be quite feasible to "mislead"
somebody trying to crack an OTP by breaking the rules
and perhaps feeding their indices of coincidence with
parts of pads that overlap, but which contain
disinformation so that they are caused to deliberately
come to the wrong answer!
Who ever said the rules had to be fair?
I think OTP's are a lot more useful and secure than people
think and with 6 Gig disks costing a little more than $100
these days it means that with the right software you have a
very fast very secure solution for many applications.
One thing I especially like about OTP is that each and every
message has to be attacked on its own. Unlike say DES,
where when the NSA breaks it they can break every message
ever sent using it. With an OTP, they have to break every
individual message and that is forever beyond the means of
even the mighty puzzle palace.
For all we know they have already broken RSA, IDEA,
Blowfish and scores of other algorithms. We just don't
know do we? But we do know that they have not nor ever
can break the OTP. Maybe they can read a message here
and there where the user slips up but that is as far as they
can ever succeed. And ever is forever.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES lifetime (was: being burnt by the NSA)
Date: Wed, 16 Jun 1999 09:51:35 GMT
Jerry Coffin wrote:
> [EMAIL PROTECTED]
> says...
> [ ... ]
>
> > > DES was specified as being suitable for sensitive but not
classified
> > > information. NOWHERE in the specification was it said to be
suitable
> > > for ALL sensitive information as long as it wasn't classified.
> >
> > Wrong. It appears on pages 1-2, where the standard says
> > "This standard will be used by Federal departments and agencies
> > for the cryptographic protection of computer data when the
> > following conditions apply..."
>
> What standard is THAT from?
FIPS 46, 1977 January 15. You can find it reprinted in
Meyer & Matyas /Cryptography, A New Dimension in Data Security/
1982, and some other places.
> Here's what FIPS 46-2 says:
> ------- start of quote ---------
> 6. Applicability. This standard may be used by Federal departments and
> agencies when the following conditions
[...]
> Anybody who wants to verify that is welcome to take a look at:
>
> http://www.itl.nist.gov/fipspubs/fip46-2.htm
Note that FIPS 46-2 is dated 1993 December 30. It did not
exist at the time in question. Incidentally, I only looked
up FIPS 46 to write my previous post, and I too was unaware
that the wording changed.
> > When a FIPS standard says "will be used", that is not a prediction
> > that agencies will choose to use the standard; it's a ruling that
> > this is the standard that they are to use.
>
> IF it actually said that, you might have some point. It provably does
> NOT say what you've claimed, rendering your entire point invalid.
You did look up _a_ standard, so I suppose we've seen worse
scholarship here on sci.crypt. But the standard in force at the
time in question was FIPS 46, and it says what I claimed it says.
I expect you'll need some time to check that out, but given how
you SHOUTED your conclusions based on the 1993 standard, will you
be willing to report what you find either way?
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
