Cryptography-Digest Digest #597, Volume #13 Wed, 31 Jan 01 14:13:01 EST
Contents:
Re: A new cipher (Mok-Kong Shen)
Re: A new cipher (Richard Heathfield)
Re: A new cipher (Benjamin Goldberg)
Re: fast signing (Bob Silverman)
Re: Free Encryption Software (Paul Schlyter)
Re: Digits of PI (Jim Gillogly)
Re: fast signing (Paul Schlyter)
Re: fast signing (DJohn37050)
Re: fast signing (DJohn37050)
Re: Digits of PI (Dido Sevilla)
Re: fast signing ("Douglas A. Gwyn")
Re: ideas of D.Chaum about digital cash and whether tax offices are ("Thomas J.
Boschloo")
Re: Why Microsoft's Product Activation Stinks ("Thomas J. Boschloo")
Re: fast signing (DJohn37050)
Did NSA change the ECDSA-standard ("Jesper Stocholm")
Re: crypto algoritm or program (Mike Rosing)
Re: Did NSA change the ECDSA-standard (DJohn37050)
Most secure code for US Citizen. (Michael Robbins)
Re: A new cipher ("Douglas A. Gwyn")
Re: On combining permutations and substitutions in encryption ("Douglas A. Gwyn")
TwoFish-VB.DLL (Brian Dofka)
Re: Most secure code for US Citizen. (Brian Dofka)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A new cipher
Date: Wed, 31 Jan 2001 11:16:18 +0100
David Finch wrote:
>
[snip]
> The source code and exe can be found at:
[snip]
It has been pointed out uncounted number of times in the
group that barely anyone has the interest/time to examine
source codes of others in order to find out the underlying
algorithms. Posting a decent description of it to the group
is the proper way.
M. K. Shen
------------------------------
Date: Wed, 31 Jan 2001 11:37:12 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: A new cipher
David Finch wrote:
>
<snip>
>
> The source code and exe can be found at:
> http://www.geocities.com/dtfinch/DC1.html
>
I had a quick look at David's code, in "non-picky" mode (i.e. I didn't
turn on all the ANSI guns!), and this is the result:
$ g++ DC1.cpp
DC1.cpp:46: stdafx.h: No such file or directory
DC1.cpp:49: io.h: No such file or directory
DC1.cpp:50: conio.h: No such file or directory
$
For those who have Visual C++, or who are prepared to edit away the
non-portable stuff (upon which the program does not appear to rely
heavily), the code may well be worth a look.
David does not, however, explain his algorithm step by step anywhere on
the site or in the zipped files (all you get is the .cpp and a Win32
(console) executable file).
(David - you would be well-advised to post a detailed,
language-independent explanation of your algorithm here, if you wish for
anyone to discuss it - don't rely on people ferreting through your
source.)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: A new cipher
Date: Wed, 31 Jan 2001 11:01:18 GMT
David Finch wrote:
>
> There seem to be a lot of bright people on this newsgroup. I recently
> wrote a new encryption algorithm but I'm having trouble determining
> it's strength with a fair level of certainty. It passes all of the
> typical tests. A single bit change in either the key or the plaintext
> results in a completely different ciphertext. The character
> frequencies are about what you would get from random data. After I
> first wrote it, I spent several days looking for and fixing all the
> theoretical weaknesses I could find. I designed it to be simple to
> understand, fast on 32bit processors, and secure enough that you
> would probably need brute force to break it.
Simply making the data look random isn't enough for security. I could
XOR a file with output from rand(), and it would look random.
So far as I can see (and I might be mistaken), your algorithm is 100%
linear, with no nonlinearity. I haven't bothered to look in more depth,
but I'm sure that with some known plaintext, your key is easily
recovered.
> There are no random lookup tables used in the encryption, which should
> make it easier to spot any major weaknesses.
Lookup tables in most ciphers are not designed to be "random" they are
designed to thwart linear and differential analysis.
> You can specify multiple rounds, but hopefully 1 round will be enough.
>
> I need people who have free time and are willing to try to break it
> without getting paid, since I'm in college and therefore have no
> money.
For a person to write a good cipher, they first have to know how to
analyse ciphers. Have you ever broken [as practice] FEAL?
Four round FEAL is insecure against both linear and differential
analysis, and is easily breakable.
If you don't know what differential analysis or linear analysis are, I
would suggest you do some searches, visit your library, etc, and read up
on them. After you've broken a few block ciphers [in reduced round
versions, if they're supposedly secure ones], *then* introduce your
cipher.
Also, don't ever say that your cipher "is secure", say [for example]
that it's secure against differential and linear analysis, and that a
chosen plaintext/chosen ciphertext attack on a reduced round version
works with X amount of work, and that using analysis method Z against
the full round method requires more work than brute force.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Wed, 31 Jan 2001 12:28:32 GMT
In article <[EMAIL PROTECTED]>,
Thomas Wu <[EMAIL PROTECTED]> wrote:
> Bob Silverman <[EMAIL PROTECTED]> writes:
>
> > In article <[EMAIL PROTECTED]>,
> > Paul Rubin <[EMAIL PROTECTED]> wrote:
> > > Bob Silverman <[EMAIL PROTECTED]> writes:
> > > > I'm just making his suggestion public. I've let e be large.
> > > > We get d = 3 and now signing is very fast and verification slow,
> > > > instead of the other way around....
> > >
> > > Um, now that the signing exponent is known, the signatures don't
> > > authenticate much any more...
> >
> > Sure. But how is it known? All you do is publish e. How
> > does someone else know then that d = 3? phi(n) is still unknown,
> > so there is no way to compute d from e....
>
> Given n and e, can't you take some x, compute c=x^e (mod n), and
> then go through a bunch of d's, checking if c^d==x (mod n)?
> Under normal circumstances, d is huge, so brute-forcing it doesn't
> make sense, but if d is fewer than, say, 40 bits...
Yep. But how can you KNOW that d is less than 40 bits??? All you
see is e.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Free Encryption Software
Date: 31 Jan 2001 13:35:37 +0100
In article <unkXjC0iAHA.272@cpmsnbbsa09>,
George Peters <[EMAIL PROTECTED]> wrote:
> "Splaat23" <[EMAIL PROTECTED]> wrote in message
> news:957tgn$aje$[EMAIL PROTECTED]...
>
>> Couldn't find any concise description of the algorithms used, so I
>> deleted it. That .zip file has ~1000 files, a little much for me to
>> wade through. Why is it using Enigma? Any particular reason I should
>> use it? I really hope this message is real and not some stupid attempt
>> at advertising...
>>
>> - Andrew
>>
>> In article <#MX$hlxiAHA.273@cpmsnbbsa07>,
>> "George Peters" <[EMAIL PROTECTED]> wrote:
>>> Greetings,
>>>
>>> An entire suite of encryption applications are available at
>>> http://www.endecs.com/uenigma.zip . It contains two file systems,
>>> client internet email, ftp and point to point communications and some
>>> source code.
>>> Well worth the download.
>>>
>>> GP
>>
>> Sent via Deja.com
>> http://www.deja.com/
>
> It is real, as you would have found if you had installed it rather than
> deleted it. All of your questions and concerns would have answered if you
> had investigated it futher.
Are you trying to launch a Trojan horse program or something?
Most people here are too sensible to install an unknown program just
because the author says "Install it -- it's real good!". Who knows
what your Install program will be doing?
So if you want people to take your stuff seriously, provide some good
descriptions of it, which will enable them to evaluate your product
BEFORE having to install it! And let THEM decide for themselves whether
your stuff is "well worth the download" or not!
--
================================================================
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: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Digits of PI
Date: Wed, 31 Jan 2001 05:35:28 -0800
Benjamin Goldberg wrote:
>
> I'm trying to convert the algorithm you suggested from using 8 bit
> values to using 16 bit values, and am having trouble. Could someone
> point out what I am doing wrong? Part of the problem is that I don't
> understand the algorithm, of course, but the change I'm making doesn't
> *seem* like one which should break it. Maybe there's some overflow
> occuring somewhere?
Yes, there is. The basic idea of what you're doing works if you go back
to the Krueger code and replace the ints with long longs. However, it
comes out slower on my 32-bit machine, since you pay extra for the fatter
arithmetic and in any case even the byte-wise version is doing its
computations a nibble at a time, which doesn't change with your short
version.
--
Jim Gillogly
Mersday, 10 Solmath S.R. 2001, 13:26
12.19.7.16.16, 2 Cib 19 Muan, Third Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: fast signing
Date: 31 Jan 2001 14:09:33 +0100
In article <9590db$5e2$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> Thomas Wu <[EMAIL PROTECTED]> wrote:
>> Bob Silverman <[EMAIL PROTECTED]> writes:
>>
>> > In article <[EMAIL PROTECTED]>,
>> > Paul Rubin <[EMAIL PROTECTED]> wrote:
>> > > Bob Silverman <[EMAIL PROTECTED]> writes:
>> > > > I'm just making his suggestion public. I've let e be large.
>> > > > We get d = 3 and now signing is very fast and verification slow,
>> > > > instead of the other way around....
>> > >
>> > > Um, now that the signing exponent is known, the signatures don't
>> > > authenticate much any more...
>> >
>> > Sure. But how is it known? All you do is publish e. How
>> > does someone else know then that d = 3? phi(n) is still unknown,
>> > so there is no way to compute d from e....
>>
>> Given n and e, can't you take some x, compute c=x^e (mod n), and
>> then go through a bunch of d's, checking if c^d==x (mod n)?
>> Under normal circumstances, d is huge, so brute-forcing it doesn't
>> make sense, but if d is fewer than, say, 40 bits...
>
>
>Yep. But how can you KNOW that d is less than 40 bits??? All you
>see is e.
If n is 40 bits then d is also 40 bits.... :-) but even in that
case, factoring n is much easier than brute-forcing d !!!!
If e is chosen to have a short length, then it's almost impossible
to avoid d will get the same length as n.
--
================================================================
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: [EMAIL PROTECTED] (DJohn37050)
Date: 31 Jan 2001 14:32:36 GMT
Subject: Re: fast signing
Bob Silverman said:
"All we need is e*d = 1 mod phi(n)
Normally we first choose e = 3, then d is large.
Suppose instead we choose a large e, resulting in d = 3.
The method will still work.
After all, Don Johnson keeps asking me to put wording into a
standards document I am editing (over my objections and deriding me
when I don't) along the lines of
"small public exponents may not be safe. It may be safer to use
large public exponents".
I'm just making his suggestion public. I've let e be large.
We get d = 3 and now signing is very fast and verification slow,
instead of the other way around...."
Don J. says "It is known that small private exponents are insecure. Also X9.31
requires the high order 160 bits of the public exponent to be binary zeros, so
how would one ever get such a small exponent by following the standard. Plus
there is a test to make sure it is not too small. So I would say that Bob is
misrepresenting my position."
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 31 Jan 2001 14:37:49 GMT
Subject: Re: fast signing
ECDSA signing should be faster than DSA signing. For 1,000 bit keys it is
about 8 times faster than DSA, if you just look at the bit calculations (back
of envelope) for bigger keys it would be a larger ratio, for smaller keys it
would be smaller but still better. See my ECDSA paper at www.certicom.com
white pages.
Don Johnson
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Digits of PI
Date: Wed, 31 Jan 2001 23:37:44 +0800
Benjamin Goldberg wrote:
>
> One silly little question, though... If I have 32 bit ints, and 16 bit
> shorts, wouldn't it be faster to calculate using shorts rather than
> chars?
>
Probably not, at least on 32-bit x86 processors in protected mode.
There is a big performance hit for performing computations on 16-bit
signed values with the x86 architecture, since you wind up adding 16-bit
prefixes for every instruction you use to perform the arithmetic. The
overhead of processing the prefix byte slows down your computation in a
big way. The arithmetic instructions for 32-bit and 16-bit x86
instructions are exactly the same, so a prefix byte gets added to
distinguish them. For 32-bit native code, 16-bit instructions get a
prefix.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Wed, 31 Jan 2001 16:31:31 GMT
> Don J. says "It is known that small private exponents are insecure. Also X9.31
> requires the high order 160 bits of the public exponent to be binary zeros, so
> how would one ever get such a small exponent by following the standard. Plus
> there is a test to make sure it is not too small. So I would say that Bob is
> misrepresenting my position."
There is something wrong with the position as stated. Any finite
integer has an *infinite* number of zeros as its "high order" bits.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are
Date: Wed, 31 Jan 2001 15:45:14 +0100
Reply-to: <boschloo<at>multiweb<dot>nl>
=====BEGIN PGP SIGNED MESSAGE=====
Ariel Burbaickij wrote:
>
> E.g . In many countires tax offices must be informed of facts of purchaes
> worth some amount ,
> considered serious . So cash is surely frawned upon in such countires
Another problem with anonymous cash is that combined with anonymous
publishing, it will not be possible to stop commercial child porn. I
would give up the former in favor of the later, although I would most
likely give up the ability of stopping child porn in favor of both
(Child porn should just be given away for free at police web sites with
a dramatic story attached and links to self-help forums. That way no-one
could make any money on Child porn anymore. Saturate the market, don't
create an artificial scarcity of the 'product', which drives up the
price and the risk child pornographers are willing to take).
I feel no desire to see child porn myself, just to make clear that there
is no hidden agenda here,
Thomas
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQB5AwUBOngW5wEP2l8iXKAJAQGCFQMaAgVy3/qIe9BJpHi4n7UUeBARQRdkTxH/
3L291uSvCPyx1w9GLwCJS7JAPedSrwJQFMY6RvoDpNk3iuKWdaXYe7mS4+Fx9NlV
L0+7xfXAN/fKuqexj7RHgDovS50q9BIruC61Sg==
=pVp7
=====END PGP SIGNATURE=====
--
=====BEGIN PGP MESSAGE=====
Comment: This dirty signed executable will twart Netsafe 4.2
Comment: Try Netsafe at <http://www.ozemail.com.au/~netsafe>
owEBzQAy/4kAeQMFADpc/IoBD9pfIlygCQEBvXYDHjqpd4mblDvTxQsubVPZAhEL
21LgMaNgT5rE9+Te4zLxaC4XpcnC7uMXSMPDWOPGHCijf9J2jo9HdrYsjQWPWUXH
JgwazJ88Df13S3QG8R3+i+uxtGxCG6OPr94nLSbdfcrO/6isT2IMdC11bnNhZmUu
Y29tAAAAAOsjLoA+/wAAdAHPgPwwdRBQLv4G/wC0TM0hLv4O/wBYLv8uXAC4ITXN
IYkeXACMBl4AtCW6AgHNIbIlzSc=
=3E5B
=====END PGP MESSAGE=====
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Wed, 31 Jan 2001 15:34:37 +0100
Anthony Stephen Szopa wrote:
>
> I think that MS cannot patent this anti-piracy feature because maybe
> they did not invent it.
>
> I DID. Or maybe I may have certainly invented it before MS.
You didn't invent this, this protection was in Titus the Fox level
password system. It calculated a checksum of the BIOS (at the 64k
segment f000) and used that as a seed for it's level passwords. They
were different for every computer. (note to readers, this was in a time
that flash-bios was not generally available yet, the ROM's really were
'READ ONLY memory').
So, the french guys who programmed this game did. (in 1992)
Thomas
(BTW Thanks a lot!! I really like copy-protection schemes and
registration requirements in software!! Yes I do!!!)
--
=====BEGIN PGP MESSAGE=====
Comment: This dirty signed executable will twart Netsafe 4.2
Comment: Try Netsafe at <http://www.ozemail.com.au/~netsafe>
owEBzQAy/4kAeQMFADpc/IoBD9pfIlygCQEBvXYDHjqpd4mblDvTxQsubVPZAhEL
21LgMaNgT5rE9+Te4zLxaC4XpcnC7uMXSMPDWOPGHCijf9J2jo9HdrYsjQWPWUXH
JgwazJ88Df13S3QG8R3+i+uxtGxCG6OPr94nLSbdfcrO/6isT2IMdC11bnNhZmUu
Y29tAAAAAOsjLoA+/wAAdAHPgPwwdRBQLv4G/wC0TM0hLv4O/wBYLv8uXAC4ITXN
IYkeXACMBl4AtCW6AgHNIbIlzSc=
=3E5B
=====END PGP MESSAGE=====
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 31 Jan 2001 17:42:02 GMT
Subject: Re: fast signing
Thanks for pointing this out, I thought it was clear from context, but
obviously not.
When compared the to modulus, the public exponent must have 160 bits of high
order zeros, according to X9.31.
Don Johnson
------------------------------
From: "Jesper Stocholm" <[EMAIL PROTECTED]>
Subject: Did NSA change the ECDSA-standard
Date: Wed, 31 Jan 2001 19:09:13 +0100
I have heard rumours, that NSA either added curves or changed curves, when
they had the ECDSA for review.
Can anyone verify this ?
/Jesper Stocholm
PS: I am not trying to start a conspiracy-thread - then I would have posted
it in alt.conspiracy
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: crypto algoritm or program
Date: Wed, 31 Jan 2001 12:25:31 -0600
Bteee wrote:
> The settings are as follow:
> The goal is to communicate secret with other players.
> Everyone can read all communication so you will need some kind of public
> key cryptation. All communication are in plain text.
> The secure level has not to be good at all (but of course it's better if
> it's high). It should be easy to use.
>
> Do PGP solve this problem or do it makes files that are not "plain text"?
> Is there any other free program that solves it or is there a simple
> algoritm that solve my problem (keep in mind that it's more important that
> it's easy to use then that it is secure it's just a game:)
There are lots of routines you can use. Far simpler than PGP, you can make
everything automatic so the user just types in some random garbage every
time to create a session key (using a hash function for example) or else
each person can generate their own private/public key pair and send the
public keys to all the other players when they login.
Encrypting files for individual users is not the same as sending them around.
I'm not really clear on what you need to do. Do you just want to share
files now and then, or do you want to "go private" and have communications
be secret between all players? Or just 2 players while everyone else is
talking in the clear? It's all possible, and there's lots of free code
around to play with.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 31 Jan 2001 18:33:59 GMT
Subject: Re: Did NSA change the ECDSA-standard
I am the editor of X9.62 ECDSA and here is what I observed:
1) Just before ECDSA was being balloted, there were concerns that curves over
2**m, m composite might be weaker than over 2**p, p prime. As nothing was
known, they were allowed, after a lot of discussion. Because of the
compositeness, some argued that they were faster; Certicom argued that they
were riskier, but lost that discussion as there was no proof.
2) Then NIST published their recommended curves, none of them were so-called
composite binary curves. There were all over prime fields or "prime" binary
fields. By agreement, NIST can use NSA for cryptographic consultation, as they
did with AES also.
3) ANSI X9 then decided to disallow composite binary types of curves, based on
NIST statements to them. This will be done is an update to X9.62 to allow
longer hash lengths.
4) Later, Nigel Smart and company found that the composite binary curves DID
have a weakness.
Draw your own conclusions. At the least I would say that the NIST curves were
chosen conservatively.
Don Johnson
------------------------------
From: Michael Robbins <[EMAIL PROTECTED]>
Subject: Most secure code for US Citizen.
Date: Wed, 31 Jan 2001 18:30:55 GMT
Pardon my naivate, I guess you guys will give me the straight dope.
Where can I get the most secure encryption code (C/C++).
I am a US Citizen.
--
Michael Robbins, CFA
Director, Debt Capital Markets
Canadian Imperial Bank of Commerce, World Markets
New York
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: A new cipher
Date: Wed, 31 Jan 2001 17:39:28 GMT
The biggest problem I see right off the bat (apart from
portability issues) is that it has a period of 140 octets
which allows the "whitened" data to be reliably sampled
and thus with known plaintext the key can be recovered
(since it is used to do the whitening).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On combining permutations and substitutions in encryption
Date: Wed, 31 Jan 2001 17:42:25 GMT
Mok-Kong Shen wrote:
> ... BTW, in this point, associations with 'fuzzy logic'
> and 'naive physics' come to mind. But I don't believe
> analogous stuffs would ever be accepted by the crypto
> community.
? "Fuzzy logic", despite the name, is an exact mathematical
discipline. (I haven't heard of "naive physics".)
------------------------------
From: Brian Dofka <[EMAIL PROTECTED]>
Subject: TwoFish-VB.DLL
Date: Wed, 31 Jan 2001 19:03:19 GMT
Hi
I'm looking for a simple sample VB project about how to use TwoFish
encryption/decryption. Does anyone out there have experience with this
DLL?
Thanx
Brian
------------------------------
From: Brian Dofka <[EMAIL PROTECTED]>
Subject: Re: Most secure code for US Citizen.
Date: Wed, 31 Jan 2001 19:05:06 GMT
Check out
http://www.counterpane.com/twofish.html
Michael Robbins wrote:
> Pardon my naivate, I guess you guys will give me the straight dope.
>
> Where can I get the most secure encryption code (C/C++).
>
> I am a US Citizen.
>
> --
> Michael Robbins, CFA
> Director, Debt Capital Markets
> Canadian Imperial Bank of Commerce, World Markets
> New York
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
