Cryptography-Digest Digest #309, Volume #12 Sat, 29 Jul 00 02:13:01 EDT
Contents:
Re: IDEA Encryption (David Hopwood)
Re: What is DES3mCBCMACi64pPKCS5? (David Hopwood)
Re: What is DES3mCBCMACi64pPKCS5? (David Hopwood)
Re: generating S-boxes (David Hopwood)
Re: Proving continued possession of a file ([EMAIL PROTECTED])
Re: What is DES3mCBCMACi64pPKCS5? (Paul Rubin)
Re: Just Curious. Are girls/women interested (Paul Rubin)
Re: IDEA Encryption (Steve Rush)
Re: counter as IV? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
Date: Sat, 29 Jul 2000 16:27:09 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: IDEA Encryption
=====BEGIN PGP SIGNED MESSAGE=====
George wrote:
> I'm new to this group, but I have read Applied Crypt. by Mr. Schneier.
> I was wanting to if there was a site I could go to that has a good
> [cryptanalysis] of IDEA encryption.
> I have been told it is the strongest cipher to break, and I have been
> wanting to give it a shot myself. Please let me know where I can find
> some information.
- From <http://www.users.zetnet.co.uk/hopwood/scan/cs.html#IDEA>
(actually the next version of it that I haven't uploaded yet):
[Def =3D definition, An =3D analysis, Inf =3D additional information,
Test =3D test vectors, Impl =3D reference implementation]
[Def, An] X. Lai,
"On the design and security of block ciphers",
ETH Series in Information Processing (J.L. Massey, ed.), Vol. 1,
Hartung-Gorre Verlag, Konstanz Technische Hochschule (Zurich), 1992. =
[Inf, An] X. Lai, J.L. Massey, S. Murphy,
"Markov Ciphers and Differential Cryptanalysis,"
Advances in Cryptology - EUROCRYPT '91,
Volume 547 of Lecture Notes in Computer Science (D.W. Davies, ed.),
pp. 17-38. Springer-Verlag, 1991. =
[Inf] The IDEA Algorithm page,
http://www.ascom.ch/infosec/idea.html. =
[Inf] Bruce Schneier,
"Section 13.9 IDEA,"
Applied Cryptography, Second Edition, John Wiley & Sons, 1996.
[[note: there is an error in the description; diagram is correct.]] =
[Inf] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
"Section 7.6 IDEA,"
Handbook of Applied Cryptography, CRC Press, 1997.
http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf, .ps =
[Patent] James Massey, Xuejia Lai,
"Device for Converting a Digital Block and the Use Thereof",
International Patent WO09118459A2, filed May 16 1991, issued
November 28 1991. =
[Patent] James Massey, Xuejia Lai,
"Device for Converting a Digital Block and the Use Thereof,"
European Patent EP00482154A1, filed May 16 1991, issued April 29 1992. =
[Patent] James Massey, Xuejia Lai,
"Device for Converting a Digital Block and the Use Thereof,"
European Patent EP00482154B1, filed May 16 1991, issued June 30 1993. =
[Patent] James Massey, Xuejia Lai,
"Device for the Conversion of a Digital Block and Use of Same",
U.S. Patent 5,214,703, filed January 7 1992, issued May 25 1993. =
[Patent] James Massey, Xuejia Lai,
[[filed Japanese Patent Application No. 508119/1991]] =
[An] Joan Daemen, Ren=E9 Govaerts, Joos Vandewalle,
"Weak Keys of IDEA,"
Advances in Cryptology - CRYPTO '93 Proceedings,
Volume 773 of Lecture Notes in Computer Science (D. Stinson, ed.),
pp. 224-231. Springer-Verlag, 1994.
http://www.esat.kuleuven.ac.be/~cosicart/ps/JD-9304.ps.gz =
[An] Joan Daemen, Ren=E9 Govaerts, Joos Vandewalle,
"Cryptanalysis of 2.5 Rounds of IDEA,"
ESAT-COSIC Technical Report 93/1, 1993.
http://www.esat.kuleuven.ac.be/~cosicart/ps/JD-9306.ps.gz =
[An] J. Borst, L. Knudsen, V. Rijmen,
"Two attacks on reduced IDEA,"
Advances in Cryptology - EUROCRYPT '97 Proceedings,
Volume 1233 of Lecture Notes in Computer Science (W. Fumy, ed.),
pp. 1-13. Springer-Verlag, 1997.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/rijmen/idea.ps.gz =
[An] L. Knudsen, V. Rijmen,
"Truncated Differentials of IDEA,"
ESAT-COSIC Technical Report 97-1.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/idea_trunc.ps.Z =
[An] J. Kelsey, B. Schneier, D. Wagner,
"Key-Schedule Cryptanalysis of 3-WAY, IDEA, G-DES, RC4, SAFER, and
Triple-DES",
Advances in Cryptology - Crypto '96 Proceedings, pp. 237-251.
Springer-Verlag, August 1996.
http://www.counterpane.com/key_schedule.html =
[An] E. Biham, A. Biruykov, A. Shamir,
"Miss in the middle attacks on IDEA, Khufu and Khafre,"
Fast Software Encryption '99 Proceedings.
Springer-Verlag, 1999.
[An] J. Kelsey, B. Schneier, D. Wagner, C. Hall,
"Side Channel Cryptanalysis of Product Ciphers",
ESORICS '98 Proceedings pp. 97-110, Springer-Verlag, September 1998.
http://www.counterpane.com/side_channel.html
[Inf, An] Ascom Systec, Ltd.
"Side Channel Attack Hardening of the IDEA(TM) Cipher,"
Ascom Systec White Paper (corrected version, May 1999).
http://www.ascom.ch/infosec/downloads/sidechannel.pdf =
[Impl, Test] Ascom Systec, Ltd.
IDEA C Source Code and Test Data (corrected version, May 1999).
http://www.ascom.ch/infosec/downloads.html =
OTOH, most of the cryptanalysis papers above are probably a bit
heavy-going for a beginner. I'd suggest starting with Bruce Schneier's
course on block cipher cryptanalysis, at
http://www.counterpane.com/self-study.html
- -- =
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYL2pTkCAxeYt5gVAQHIbQf9F0E9Dl2VdhZifrnZ9qMVK/mNF2ubGaFy
aY+vayx8hLcgZ1nRiiEHaZ7hcBhKEDZdkHmIhzI3jaSmm/q11amFw+bt+gnDn0OY
DCbQMXDtm+jMUKe9fF8gRcz/t7MLdXiwNSI5G3COnkf0PxuRlTsQTNZOBt5AxvV5
9/xUwZ6PCHnyY6lsq3iV1avZEqvuNVw2ys2U14D+YTjDmc6AVy+P52cqjOhvIEOV
X3rt+zCiRTnfDdn40NRb9gTEjQWoWgsOapA8fLBDNSd6ohqlSNyZKzxtNZINxir0
tvQu1hy8kckcxsj1RhjEbjmWYG3iVTfwqO9dN8WDemDZvuxC0MNx6g=3D=3D
=3Dm1Qj
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 29 Jul 2000 16:33:33 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What is DES3mCBCMACi64pPKCS5?
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> I'm not terribly keen on the idea of MACing the ciphertext: it violates
> the 'Horton principle' that you should validate the *meaning* of what's
> being said as closely as possible.
ISTR reading an analysis of IPsec that said that MACing the ciphertext
(which is what IPsec does) cannot be less secure than MACing the plaintext,
although I can't remember whether that was proven or not. I'll try to dig
up the reference.
> > > Someone else said the mode is signature-only, i.e. there's no cipher
> > > output. I hope that's incorrect. I'd like to be able to get an
> > > encrypted and authenticated ciphertext from a plaintext in a single
> > > module operation.
>
> I'm afraid that you can't do this. I'm not sure that it would be of
> particularly great benefit anyway, since you have to do the same number
> of DES encryptions anyway. You'd reduce the amount of data transferred
> between the host and the module by a third, though. Is that really a
> major issue?
In hardware, the encryption and the MAC computation could be done in
parallel. I don't whether nCipher's stuff does that, but PKCS #11/Cryptoki
has "Encrypt and MAC" and "Verify and decrypt" operations partly for that
reason (and also because the I/O bandwidth may be as much of a limit as
the speed of the cipher in some cases).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYL4xTkCAxeYt5gVAQF9swgAhz6X5bt+tGwBUYYLN1WFhaipBlsOGgAw
dPAc/fRk9FxOeTmTRzrKaD5lslxe2vpWMUBMeJeDx8ZC9x81apD7121h0vHqL/ck
gTQUckmVUXl9K+L/Y1PjG95I6BtdJ/GaiF4MpZKYB3kP8rqYaiShBLS+ep1I1Wlf
EcEMdMME4jB62boo2p297Z6rkdC7LCK8lR98ymhsWN0ddPnweyw7xVOkjFdvUDIa
o2svFyNCv4Wlf53temh2cyGS2rhMpCjLdf0tNXbN9wDrT1UEaQS+7s301GdIJtDo
pQ83DGckt1ZZmP37KB7GuZGMsLK4EfkPoIBFCj7EXmA41iDZ/Wvwzw==
=tC5F
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 29 Jul 2000 16:38:59 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What is DES3mCBCMACi64pPKCS5?
=====BEGIN PGP SIGNED MESSAGE=====
Paul Rubin wrote:
> In article <[EMAIL PROTECTED]>,
> David Hopwood <[EMAIL PROTECTED]> wrote:
> > U.S. National Institute of Standards and Technology,
> > NIST FIPS PUB 113, "Standard on Computer Data Authentication,"
> > U.S. Department of Commerce, May 1985.
> > http://www.itl.nist.gov/div897/pubs/fip113.htm
> >
> >with DES replaced by 3DES (and preferably with independent 168-bit key=
s
> >for the cipher and MAC). *However*, if you use that standard, you shou=
ld
> >prepend the plaintext length to the plaintext before encrypting and
> >MAC'ing, and check it on decryption.
> =
> Thanks, I also found a description of CBC-MAC in FIPS pub 81, which
> describes the standard DES chaining modes. Why do you need to prepend
> the length? Deleting blocks would make the MAC come out wrong, as far
> as I can see.
Here are the other references for CBC-MAC in SCAN
<http://www.users.zetnet.co.uk/hopwood/crypto/scan/>:
[An] M. Bellare, R. Gu=E9rin and P. Rogaway,
"The security of cipher block chaining,"
Extended abstract in Advances in Cryptology - Crypto '94 Proceedings,
Volume 839 of Lecture Notes in Computer Science (Y. Desmedt ed.),
Springer-Verlag, 1994.
Full paper available at
http://www-cse.ucsd.edu/users/mihir/papers/cbc.html =
[An] Bart Preneel, P.C. van Oorschot,
"A new generic attack on message authentication codes,"
Advances in Cryptology - Crypto '95 Proceedings,
Volume 963 of Lecture Notes in Computer Science (D. Coppersmith, ed.),
Springer-Verlag, 1995. =
[An] Bart Preneel, P.C. van Oorschot,
"MDx-MAC and building fast MACs from hash functions,"
Advances in Cryptology - Crypto '95 Proceedings,
Volume 963 of Lecture Notes in Computer Science (D. Coppersmith, ed.),
pp. 1-14. Springer-Verlag, 1995.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/preneel/mdxcrypto95.ps =
[An] Erez Petrank, C. Rackoff,
"CBC MAC for Real Time Data Sources,"
To appear in the Journal of Cryptology.
http://www.cs.technion.ac.il/~erez/pra2.ps
Attacks on CBC-MAC that involve changing the message length are described=
in the last three of these papers, IIRC, but it's a good idea to read all=
four.
> >Normally the MAC is applied to the ciphertext, but your module might
> >apply it to the plaintext (probably after performing the PKCS#5 paddin=
g).
> =
> Aha, this is the part I was missing. Attaching a CBC MAC of the
> plaintext to a ciphertext that was encrypted in CBC mode with the same
> key is insecure because of CBC mode's error recovery property: [...]
That's why I said "preferably with independent 168-bit keys for the
cipher and MAC". If the MAC is applied to the plaintext, then the cipher
and MAC keys MUST be different; if applied to the ciphertext, they still
SHOULD be different (using the same key for more than one algorithm
generally invalidates security proofs, including the one given in
"The security of cipher block chaining").
[...]
> So the following sounds reasonable, based on FIPS 81 and 113:
> =
> - Take plaintext message and pad with PKCS5
> - Encrypt the padded plaintext in CBC mode with a random IV.
> Ciphertext is the IV followed by the CBC output.
> - Take the ciphertext and encrypt it *again*, in CBC mode with IV=3D=
0.
> The last block of the output is the MAC. Discard the rest of the
> output.
Most implementations do the encryption and the MAC in a single pass (with=
two encryptions per block), but that's equivalent to the above, yes.
- -- =
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYL6WjkCAxeYt5gVAQEbcAf+J3EOI5lGmw3t4cAtfN9CWb3xDgRtUOqB
KzoskERpPGEN57r2ZDezXKwmOFwn7gVvTdJ7iVKmrK4OzKZQAbAvtIrSywGQJKNw
Qla4voVzWBTiLtc213xki3v1t1gmUYCbx//rFijtPqKKIivvRpXfI75Fz/Zj0zPr
GHWkOypYEvbUCmGateQyoYgmbmP/Fvw0kRN+998ZEqTSMECOy/7tEm/CEKT/9kBo
AyUZeaYHJijr3tQsG4wnI2HT6m7KN8R9+MAEEkWJHfmpd/FUAxxx8ZDXzwng5hAa
CDgrRTmahcAGMmkeihHgslU7+EEwkU/s2koaSAI607vmWa5zAB7GQQ=3D=3D
=3D28kc
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 29 Jul 2000 17:02:58 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: generating S-boxes
=====BEGIN PGP SIGNED MESSAGE=====
Tom Anderson wrote:
> On 28 Jul 2000, Mack wrote:
> > >i was wondering about how one generates S-boxes.
[...]
> > The three usual criteria are the SAC,
>
> if a and b differ by 1 bit, S(a) and S(b) differ by, on average, half
> their bits. do we care more about the actual average (ie 3.9 bits is good,
> 2.4 is bad) or the deviation from the average (3.9+/-2.1 is bad, 2.4+/-0.2
> is good)? or both? should this be weighted with some nonlinear function,
> so that 2.4 is more better than 2.3 than 3.9 is better than 3.8?
What we want is that the distribution of differences between S(a) and S(b)
is as expected for a random function. IIRC it should be a binomial
distribution - Terry Ritter's site has some information on this.
Perhaps you could define a metric for the "goodness" (or more precisely
"badness") of an S-box with respect to the SAC, based on the results of a
statistical test of whether the output differences are consistent with the
expected distribution, for some set of small input differences.
[...]
> > You could simply multiply SAC level and Nf then divide by Max Xor entry.
I suspect you'd have to do some experiments to see what type of weighting
is reasonable. To avoid having to know this in advance, try plotting the
three parameters for each S-box as a point in a 3D volume - then there
will be a surface such that all possible S-boxes are to one side of it,
and those that are closest to it are optimal in some sense.
(You could write a program to output (SAC, Nf, MaxXor) triples for
randomly generated S-boxes of various sizes, and import the results into
Mathcad or some statistical package. I'd quite like to see what the results
of that are.)
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYL/6zkCAxeYt5gVAQHsEwf9EvcwXAAhKPDZlxxXZQY/H9JbHAZYn5B2
7wsp9y3XiApS14n++BZR82UD91E0m9pYLkz5c0pYBwBNI6nz7+SDoCD448pxFPmN
CmZpIz5uvsapjQpSgAcj3SQmNtBcuo54XBKraGLFrq+9R4Jtlb0HcvC4d339fits
vIDmvzWK3IeurGBM7uog47I6uUvnGvREeqDcEoeL+PG9wHhUSHcH4MVMzqXvkFq6
ZtGx62FkXkMZQAdqBLBGNakWVXrUq+ztuiFM9cM5X1kfi8rrnh7EVd2H1N+Qo59Y
dpd6hI04u7uZOk7ac1EC21y2zCriQtpke1owt8emAXl78hjVopEPNg==
=v75s
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Proving continued possession of a file
Date: Sat, 29 Jul 2000 04:46:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> [EMAIL PROTECTED] wrote:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Mark Wooding) wrote:
> > > A while ago, I was asked to come up with some mechanism
> > > whereby a server could ascertain whether a client, which
> > > had previously transferred a particular file to the server,
> > > still had a copy of that file itself.
> [...]
> > Alice and Bob both know the message M initially.
> >
> > Alice generates:
> >
> > p, q, c, k = randomly chosen
> > n = p * q
> > a = k * (M^(-1)) mod (p-1)(q-1)
> > b = c^k mod n
> >
> > Alice publishes a signed file containing:
> >
> > n, a, b, c
> > Alice and Bob's names, and the filename for M
> >
> > Alice can then forget everything. Now Victor (or anyone
> > else) can verify that Bob truly has a copy of Alice's file.
> > Victor generates:
> >
> > r = randomly chosen < n
> > d = c^r mod n
> >
> > and gives d to Bob. Bob then calculates:
> >
> > e = d^M mod n
> >
> > and gives e to Victor. Finally, Victor checks that:
> >
> > e^a mod n == b^r mod n
> >
> > If they are equal, then Victor concludes that Bob truly has
> > Alice's file.
>
> Alice can store M mod (p-1)(q-1) instead of M (unless (p-1)(q-1) > M,
> but that means the data needed to verify possession of a file is at
> least as large as the file itself).
Alice doesn't have to store M or anything else. The whole
point was to reduce her storage to zero. Anyone who has the
published (n,a,b,c) can verify that Bob truly has a copy of M.
Each of the numbers (n,a,b,c) are maybe 1024 bits long, while
M can be gigabytes.
Maybe you meant *Bob* could store M mod (p-1)(q-1) as a way
to cheat. He can't do that because he doesn't know p and q.
Alice randomly generated p and q, used them to create (n,a,b,c),
then deleted them. Once she does that, no one knows p and q,
so no one can help Bob cheat.
LCB
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: What is DES3mCBCMACi64pPKCS5?
Date: 29 Jul 2000 05:27:18 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
>> > Someone else said the mode is signature-only, i.e. there's no cipher
>> > output. I hope that's incorrect. I'd like to be able to get an
>> > encrypted and authenticated ciphertext from a plaintext in a single
>> > module operation.
>
>I'm afraid that you can't do this. I'm not sure that it would be of
>particularly great benefit anyway, since you have to do the same number
>of DES encryptions anyway. You'd reduce the amount of data transferred
>between the host and the module by a third, though. Is that really a
>major issue?
Sorry I skipped this earlier. Yes, the number of transactions is
significant. The plaintext messages I'm encrypting are quite short,
typically 20-30 characters, or maybe 12 DES operations (4 blocks *
3DES). That operation takes about 10 msec, of which maybe 0.2 msec is
spent transferring the data and doing the encryption, and the other
9.8 msec is SCSI bus command overhead. The bottleneck with these
short plaintexts is the number of separate transactions, not the
amount of data or DES operations.
I've heard the PCI bus version of the module has much lower
transaction overhead, so we'll probably use it for future installations.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Just Curious. Are girls/women interested
Date: 29 Jul 2000 05:31:58 GMT
In article <8ltmh2$mcg$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>in cryptography? Is there any female poster on this board? Any
>prestigious woman in the field at all? Thank you for your response.
Off the top of my head, Jennifer Seberry, Shafi Goldwasser, Cynthia
Dwork, Hilary Orman, and yes, Dorothy Denning all come to mind.
All of them (usually) have the good sense not to post here though.
------------------------------
From: [EMAIL PROTECTED] (Steve Rush)
Subject: Re: IDEA Encryption
Date: 29 Jul 2000 05:33:21 GMT
Helger Lipmaa [EMAIL PROTECTED]
wrote:
>... I can very easily break OTP with a chosen plaintext attack, using
>two messages only.
If you have two messages encrypted with the same key, it *can't* be a one-time
pad.
==========================================================================
==============
If it's spam, it's a scam. Don't do business with Net abusers.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: counter as IV?
Date: Sat, 29 Jul 2000 01:39:12 -0400
Mok-Kong Shen wrote:
> ... If the opponent ever gets
> the key for one block, he can decrypt the whole message.
That's the case for practically any block cipher used in any
chaining mode.
------------------------------
** 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
******************************
