Cryptography-Digest Digest #560, Volume #11 Sun, 16 Apr 00 21:13:01 EDT
Contents:
Re: Why is this algorithm insecure? (Newbie flamefodder) (stanislav shalunov)
Re: GOST idea (Tom St Denis)
Re: Why encrypt email... (Jerry Park)
Re: Encrypt the signature? ("Scott Fluhrer")
Re: One Time Pads Redux ("Joseph Ashwood")
Re: Why is this algorithm insecure? (Newbie flamefodder) (NFN NMI L.)
Re: Why is this algorithm insecure? (Newbie flamefodder) (David Hopwood)
Re: Observer 16/4/2000: "Jack Straw wants the keys to your office. Don't let him in
..." ("PJS")
Re: Why encrypt email... ("Joseph Ashwood")
Re: new Echelon article ([EMAIL PROTECTED])
Re: Encode Book? (greenjh)
Re: One Time Pads Redux ("Trevor L. Jackson, III")
Re: My STRONG data encryption algorithm ("Trevor L. Jackson, III")
Re: My STRONG data encryption algorithm (Tom St Denis)
Re: Why is this algorithm insecure? (Newbie flamefodder) ("Trevor L. Jackson, III")
Re: Why encrypt email... (Guy Macon)
----------------------------------------------------------------------------
Subject: Re: Why is this algorithm insecure? (Newbie flamefodder)
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sun, 16 Apr 2000 22:38:12 GMT
Richard Heathfield <[EMAIL PROTECTED]> writes:
> > or make Alice send some chosen plaintext).
> Skulduggery? Surely not! :-)
Many protocols would echo whatever Bob sends (or pieces of it).
Mallory could pretent to be Bob in the end of the transaction and
decrypt everything that happened before.
> That's worrying. I'll try to crack it on that basis to see if you're
> correct.
If I understood your description correctly, if you encrypt two
messages of the same length with the same key, XOR or the two
ciphertexts is the same as XOR of plaintexts. That reveals way too
much information about plaintexts.
> > The task of brute-forcing 2^128 different keys is out of reach for any
> > known adversary.
> But wasn't it done recently?
No. If I am not mistaken, the largest publicly known brute-force
attacks are against 56-bit keys. It's probably true that 64-bit keys
can be brute-forced today by well-equipped adversaries (governments of
large countries or many co-operating users on the Internet).
But 2^128 is well out of reach by today's standards. Computing based
on new physical principles would be required to brute-force that.
You might be confusing this with something like RSA-512 challenge.
RSA isn't a symmetric cryptosystem.
> Is it worth persevering with this algorithm, but adding partial
> rotations and partial XORing, as another poster suggested?
For fun and to learn--sure. But even for fun you could try different
(more traditional) designs, such as a block cipher based on Feistel
networks. It'll usually be faster, won't require loading of the
complete plaintext into memory, and will possibly be more secure.
Feistel networks are described in _Applied Cryptography_ by Bruce
Schneier, 2nd edition (a must-have first book for anyone plaining with
inventing or implementing cryptosystems). They've been described in
this newsgroup before numerous times.
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: GOST idea
Date: Sun, 16 Apr 2000 22:39:34 GMT
Tom St Denis wrote:
>
> Mok-Kong Shen wrote:
> >
> > Tom St Denis wrote:
> > >
> >
> > > Well my idea cannot technically be any worse then before since F(x) 2x^2
> > > + x is a permutation in GF(2^w). Another balanced approach would be
> > > todo this
> >
> > Could you explain why a permutation doesn't affect the avalanche?
> > Thanks.
>
> No the permutation cannot hinder the avalanche. It in fact increases
> the avalanche.
That's too vague, sorry. It can't hinder it in this case since the S
function is simply a permutation itself. And since the quadratic
used is a permutation it has no bias towards any particular value. It's
like doing
F(x) = S(x + c), For any constant 'c'. You are just changing the order
of the outputs, not the properties of S() itself.
Tom
------------------------------
From: Jerry Park <[EMAIL PROTECTED]>
Subject: Re: Why encrypt email...
Date: Sun, 16 Apr 2000 17:48:33 -0500
David Crick wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Hi, I am doing a paper on email encryption and I have two theories:
> >
> > 1) The level of encryption depends on the information being encrypted.
>
> Only in military and government systems.
>
> > Much email is non-sensitive info so encryption is not used.
>
> There is no reason why you should not encrypt everything.
> (The speed issue with modern hardware and ciphers no longer
> is an issue. There are also enough free and tested algorithms
> so that patent issues, etc. are not an issue.)
>
> > At other times, like for medical records, email is encrypted to
> > protect confidential info.
>
> This is one case where encryption seems to be needed and therefore
> the bodies have the incentive to do so.
>
> > 2) Email encryption is not used because users don't know how much it is
> > worth. Email encryption developers need funds to create privacy, but
> > different users value privacy differently. Many users want free online
> > privacy, expecting it to be "provided" by the Net. Others, like
> > corportate users, will pay resonable fees to companies (like Verisign)
> > because they need strong encryption.
>
> I don't think cost comes into it at all.
>
> > What I need are papers, books, or other documents that back up (or
> > refute) the above claims. If anyone has user survey data (how users
> > value email encryption) that would be ideal!
> >
> > Thank you,
> > Stanley
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> Here I think are some true answers:
>
> (1) The average user doesn't see the need to encrypt their
> e-mail ("I don't have anything to hide.")
>
> (2) Those interested in trying encryption find most current
> systems are too complicated and are discouraged.
> ("It's too much effort.")
>
> (3) There are only a small percent of people using encryption.
> They therefore tend to stand out and look like extremists
> who it seems must have something to hide. This puts people
> off. ("Child porn", "Terrorism", etc)
>
> (4) Some governments and other bodies try to suppress the
> use and spread of encryption, or at the very least do
> not actively promote it.
>
> Best wishes,
>
> David.
I would add that most people using email are do not have the time or
inclination to learn more that what is necessary to operate the computer.
People are, for the most part, unwilling or unable to set up systems for
security, or to even understand the privacy issues.
That is not to say at all that most people are unable to understand, but that
the press of business does not allow them the leisure to study and learn the
issues involved.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Encrypt the signature?
Date: Sun, 16 Apr 2000 12:21:51 -0700
<[EMAIL PROTECTED]> wrote in message news:8ci7bs$rj4$[EMAIL PROTECTED]...
> Dear all,
>
> Just a beginner question:
>
> If I want to have a crypted signed document, have I to
> encrypt the signature ???
As previous posters said, you strictly speaking don't need to. However, if
you don't, and you sign and encrypt the message, then you allow the attacker
to verify if a particular plaintext was the encrypted message (by checking
the signature). This cannot be used to rederive the message (unless the
attacker had virtually all of it already), but it may be useful if the
attacker got what might be the plaintext by other means, and wanted to
verify it. Whether this is actually a weakness depends on the exact attack
model. Of course, if you include something other than the plaintext in your
signature (say, a salt which you send encrypted), you are also covered.
--
poncho
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: One Time Pads Redux
Date: Sun, 16 Apr 2000 15:53:30 -0700
> Am I missing something here?
>
> If you have the ciphertext and the plaintext, what more do
you
> need? What's the point of recovering the key, particularly
> if it's never going to be used again?
I started with no knowledge of the original plaintext. I
exploited the fact that Bob's ciphertext was reencrypted
using Alice's unknown key, and the fact that from that I
could recover Alice's pad. Perhaps an example would help
clarify (all values are in hex):
Bob wants to send Alice A3
Bob generates a OTP of 76
Bob Encrypts to D5 and send to Eve and Alice
Alice generates a 98
Alice Encrypts to 4D and sends to Eve and Bob
Eve recovers Alices OTP 98 by D5 XOR 4D
Bob Decrypts 4D to 3B and sends to Eve and Alice
Eve and Alice decrypt to A3
Eve never knows Bob's original plaintext until after
recovering Alices pad and using it.
Joe
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: Why is this algorithm insecure? (Newbie flamefodder)
Date: 16 Apr 2000 23:19:51 GMT
<<Well, as NFN NMI L.>>
It's S.T.L. That whole "NFN NMI" thing is a joke, from Star Trek: The Next
Generation. You know. No First Name No Middle Initial Data? Har de har har.
Ah, forget it. :-D
-*---*-------
S.T. "andard Mode" L.
STL's Quotation Archive: http://quote.cjb.net
------------------------------
Date: Sun, 16 Apr 2000 04:06:42 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Why is this algorithm insecure? (Newbie flamefodder)
=====BEGIN PGP SIGNED MESSAGE=====
Richard Heathfield wrote:
[...]
> The algorithm is too simple to be secure, surely. It also suffers from
> inefficiency, having a time complexity which I believe to be O(pk) where
> p is the plaintext length and k is the key length, although - again - I
> could be wrong about this.
That in itself is not a problem - modern block ciphers could also be
considered to be O(pk), since the number of rounds is usually the same
as or linearly related to the number of internal subkeys, and the total
size of the subkeys is typically greater than the size of the input key.
> Having said that, it does lend itself to
> stupendously long keys - http://users.powernet.co.uk/eton/crypto/cipher
> contains a cipher (which I daren't reproduce here, since all 8 (or, if
> you prefer, CHAR_BIT) bits of each byte are in the cipher 'space') which
> was encrypted using a key over 20,000 bits long. (I never really
> understood why people were hung up on 56 and 64 and 128 bits!)
For the most part, 56 and 64 bits were only proposed for political reasons
for ciphers that were intentionally designed not to be secure in the long
term. 128 bits, OTOH, is quite sufficient to prevent brute force attacks
under very conservative assumptions, and for other types of attack it is
the structure of the cipher, not the key length, that is most significant.
(That does not mean there are never cases where it is desirable or
convenient to use keys longer than 128 bits.)
> Here's the algorithm, which I rather self-consciously call CDX-1:
>
> Read the /whole/ plaintext into a buffer.
> Read the whole of the key into another buffer.
>
> For each byte of the key
> Pick some number B with which that byte of the key is uniquely
> identified (I used a bunch of primes)
> Rotate the buffer left by B bits.
> Perform a Vigenere-style XOR of the key all the way along the buffer.
> Next
>
> Write out the buffer to the ciphertext file.
This is almost equivalent to a simple Vigenere with a different key
(of the same length). Consider that rotating the buffer in each loop
iteration is equivalent to rotating the string that will be XOR'd
against the buffer (with a final rotation of the ciphertext at the end).
Therefore, the whole algorithm can be described as:
1. Construct a series of (number of key bytes) strings, each of which
is found by repeating the key to fill the buffer size, and rotating
by the sum of some subset of the B values.
2. XOR together all of the strings constructed in step 1 to give a
keystream.
3. XOR the plaintext with the keystream.
4. Rotate the output of step 3 by some amount to give the ciphertext.
For simplicity, first assume that the key length evenly divides the
buffer size. In that case, the keystream will repeat with a period
equal to the key length. I.e. you can effectively ignore how the
keystream was constructed and treat the cipher as a Vigenere, then
rotate the recovered plaintext (the correct rotation amount will
probably be obvious by looking at the meaning of the message).
Note that works despite not knowing the exact rotation amount in each
round (which is key dependent), because of two facts:
- rotating a string of period n and length a multiple of n gives a
string of period n.
- XORing two strings of period n gives a string of period n.
If the key length does not evenly divide the buffer size, then things
are more complicated, but not by much: the keystream will still tend
to repeat at intervals equal to the key length with fairly high
probability, and I believe that would be sufficient for some of the
techniques used to break Vigenere ciphers to work.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOPktlDkCAxeYt5gVAQFFvQf/fX3PyVE68jmON21/Oi2gz0zXB1SAy7QL
dN0PpvPh7Xi80eTz3LwZRtJKd0q0SyhFDFR/17B6gded25YcdwPoQu/OjGCC7YDf
rjNt1RIVK7i4+UsCmwldw0l42yS17A7xT6hND+ysiLAukCtT9DJNsLaB4/4EsBET
cERW0Xc9XOdHYPRJp6LbzsYycGv/8pRkrUPUNUaXo9VsWRwl7B7icwe551iEe0xi
2QFM52Z8tfHzSNbIsD3gs/2Aq2+Wuill5E1ZvX8cTQwWUbkUOVmh5TNJxOtdUIqY
H9LtZPMgIk0aP1wquoKFB8ZVzkA5NNj03pkK6QixX51HUYFD5GvfZw==
=xDSr
=====END PGP SIGNATURE=====
------------------------------
From: "PJS" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,uk.business.accountancy,talk.politics.crypto
Subject: Re: Observer 16/4/2000: "Jack Straw wants the keys to your office. Don't let
him in ..."
Date: Mon, 17 Apr 2000 00:36:14 +0100
NoSpam wrote in message
<[EMAIL PROTECTED]>...
>This scenario is just one of several envisaged by Dr. Charles Lindsey of
>Manchester University in a fascinating commentary on the legal farrago
which
>is currently being railroaded through the Commons by the Interior Ministry
>(prop. J. Straw). The RIP Bill is such a crazed piece of legislation that
>one wonders if the Government hasn't taken leave of its senses. Bemused MPs
>say they don't understand this encryption stuff and hide behind the
>assumption that the Home Office must know what it's doing.
---
Dr Lindsay isn't going to go to jail for revealing this is he?
--
Will the last person to be eaten
by the Fnord please turn the light out?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Why encrypt email...
Date: Sun, 16 Apr 2000 16:32:58 -0700
Well I can give you a couple of specifics. Last year I
worked at a company of 105 people, I was the only one that
used PGP. At USC they have approximately 34000 users
accounts and under 332 registered PGP keys (26 of which are
expired or revoked). On the other hand some corporation have
a very high incidence of PGP users, NAI (owners of PGP)
comes to mind as high probability. In my experience more
people use PGP than S/MIME, probably because PGP is better
known, and free. The most common complaint is that "it's
hard to use" I have never had a problem with it, and no one
that I've ever introduced to PGP has ever had a problem (at
least since version 5).
Joe
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Sun, 16 Apr 2000 23:19:57 GMT
An interesting report at NBC:
http://www.msnbc.com/news/394993.asp?cp1=&cp1=1
U.S. spying pays off for business
Same old claims that intelligence gathering is _solely_ to thwart
bribery but includes confirmation that Clintonistas made economic
intelligence gathering by CIA/NSA a policy matter, and started
requiring the formation of a "Daily Economic Intelligence Brief."
------------------------------
From: greenjh <[EMAIL PROTECTED]>
Subject: Re: Encode Book?
Date: Mon, 17 Apr 2000 00:51:04 +0100
On Mon, 10 Apr 2000 16:11:44 -0400, Craig Storey <[EMAIL PROTECTED]>
wrote:
>I caught the last two minutes of a radio news broadcast about a UK girl
>who developped an simple encryption method that won awards. Her father
>is a math professor working on encryption. Together they co-wrote a
>book. I didn't catch much but was interested in reading her book. It
>may have been called Encode or In code. Does anyone know anything about
>it?
>
>Pleas reply to: [EMAIL PROTECTED]
I think that this young lady was interviewed on UK Radio 4 about
two weeks ago. She has an Irish accent, but I cannot say whether
she is from the North or the South (not that that matters to me).
She came over as intelligent, modest and well-informed about the
field, so far as she could when addressing a(n intelligent)
general audience.
I tried searching www.bbc.co.uk for "Sarah Flannery", but all I got
was soccer results. :-(
Regards,
John Green
------------------------------
Date: Sun, 16 Apr 2000 20:49:45 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: One Time Pads Redux
Joaquim Southby wrote:
> This may have been discussed already; I could not find it in the reams of
> messages in sci.crypt about one time pads. (To be honest, I gave up
> after reviewing the first 50 or so -- Deja is a dog.)
>
> From what I've read about OTP, the major drawback is the key
> distribution. Would something like the following help to alleviate that
> and still be secure?
>
> A) Bob and Alice each have a RNG at their disposal. These do not need to
> be synchronized or even similar -- they just have to create numbers
> acceptably random for an OTP.
>
> B) Bob enciphers a message by XOR'ing the plaintext with numbers from his
> RNG; he keeps a temporary copy of the numbers he used for this message.
> He sends the enciphered message to Alice.
>
> C) Alice repeats this process using her RNG and sends the result back to
> Bob.
>
> D) Bob uses his temporary copy of the numbers he used the first time,
> XOR'ing them with Alice's return message to remove his stuff from the
> mix. He sends the result to Alice.
>
> E) Alice uses her temporary copy to remove her encipherment and retrieve
> the original plaintext message.
>
> F) Both of them destroy their temporary copies of their RNG numbers.
>
> The obvious drawback I can see to this is how to keep track of what copy
> of RNG output goes with what message. In an automated system, messages
> could have headers identifying uniquely identifying themselves and their
> accompanying RNG output files. This would work best when the exchange of
> messages is completed within a very short period of time.
>
> As I mentioned, this method would seem to preclude the need to distribute
> OTP's to multiple users. It seems so simple (other than the correlation
> of messages to RNG output) that there must be something wrong with it.
A simple flaw in this exchange is that anyone monitoring the sequence an
catching either the first pair of messages or the last pair of messages can
trivially reveal the plaintext. If the messages are numbered with zero being
the original plaintext we have the following equations. (Note that I'm using
+/- as logical operations, where the actual operation, XOR, is the same for
both logical operators).
M0 = text
M1 = M0 + Kb
M2 = M1 + Ka = M0 + Kb + Ka
M3 = M2 - Kb = M0 + Ka
Now mix the messages to reveal the keys
Ka = M2 - M1
Kb = M2 - M3
And use them to reveal the text
M0 = M1 - Kb
M0 = M3 - Kb
------------------------------
Date: Sun, 16 Apr 2000 20:55:05 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: My STRONG data encryption algorithm
Tom St Denis wrote:
> Nobody Home wrote:
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> > >Hehehehe, I was like this once, basically it looks like a salted
> > >Vinegere cipher (spelling?). Which given the length of the passphrase
> > >is trivial to break. Your usage of random() to increase the entropy of
> > >the key is not going to work, so your essentially limited to the
> > >passphrase.
> > >
> > >Essentially this is not at all secure, but keep up the research, I
> > >started this way too...hehe
> >
> > I know how you feel, Tom. I remember back in grade school when my spelling,
> > grammar, and punctuation were as bad as yours, hee hee hee.
>
> Hey grammar is not my strong point. I am trying to develop my math
> skills (which is not easy on my own).
Tom,
Who else posts on this newsgroup and expresses contempt for
spelling/grammar/usage conventions? Hint: he expresses contempt for just about
everything he mentions. Is this your role model?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: My STRONG data encryption algorithm
Date: Mon, 17 Apr 2000 00:50:17 GMT
"Trevor L. Jackson, III" wrote:
>
> Tom St Denis wrote:
>
> > Nobody Home wrote:
> > >
> > > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > >
> > > >Hehehehe, I was like this once, basically it looks like a salted
> > > >Vinegere cipher (spelling?). Which given the length of the passphrase
> > > >is trivial to break. Your usage of random() to increase the entropy of
> > > >the key is not going to work, so your essentially limited to the
> > > >passphrase.
> > > >
> > > >Essentially this is not at all secure, but keep up the research, I
> > > >started this way too...hehe
> > >
> > > I know how you feel, Tom. I remember back in grade school when my spelling,
> > > grammar, and punctuation were as bad as yours, hee hee hee.
> >
> > Hey grammar is not my strong point. I am trying to develop my math
> > skills (which is not easy on my own).
>
> Tom,
>
> Who else posts on this newsgroup and expresses contempt for
> spelling/grammar/usage conventions? Hint: he expresses contempt for just about
> everything he mentions. Is this your role model?
I think I know who you are talking about.
To be honest I play 'devils advocate' sometimes just to stir '!@!!' up.
Sometimes I try to out-smart myself. Generally I have a clue about the
math going on, but when you ask.... er. prove Schoofs Algorithm or
something like that... er no.
I am trying to get a book called 'Fundamentals of Number Theory' to fit
inside my head... hehe.
Tom
------------------------------
Date: Sun, 16 Apr 2000 21:08:09 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why is this algorithm insecure? (Newbie flamefodder)
Richard Heathfield wrote:
> stanislav shalunov wrote:
> >
> > The task of brute-forcing 2^128 different keys is out of reach for any
> > known adversary.
>
> But wasn't it done recently?
You need to distinguish various kinds of key. The big division is between
asymmetric systems, which require keys with special structure and symmetric keys
where no special structure is necessary.
For symmetric systems the only concern is weak or semi-weak keys, which are
special values that one should avoid. Typically there are very few (4, 8, etc)
such values for a given cipher. Other than that any set of bits is as good as
any other set of bits. So the keyspace is directly related to the keysize by
the formula space = 2^size.
Asymmetric keys are rare due to the special structure they require. For
instance, RSA keys have to be the product of a few large primes. The density of
such numbers is low. So the relationship space = 2^size must be modified. For
instance RSA keys are measured in bits, but 512-bit RSA keys are now considered
breakable. 768-bit keys, not yet.
There are tables from various sources that compare the strength of ciphers based
on their key spaces (rather than sizes).
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Why encrypt email...
Date: 16 Apr 2000 21:04:54 EDT
In article <8dcueg$agt$[EMAIL PROTECTED]>, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
>
>Hi, I am doing a paper on email encryption and I have two theories:
>
>1) The level of encryption depends on the information being encrypted.
>Much email is non-sensitive info so encryption is not used. At other
>times, like for medical records, email is encrypted to protect
>confidential info.
Encrypting non-sensitive info increases security. If I usually send
non-encrypted, then suddenly start encrypting, it tells an attacker
something about me. Better to always encrypt. If you have a dedicated
line, better to always be sending encrypted garbage that gets discarded.
>2) Email encryption is not used because users don't know how much it is
>worth. Email encryption developers need funds to create privacy, but
>different users value privacy differently. Many users want free online
>privacy, expecting it to be "provided" by the Net. Others, like
>corportate users, will pay resonable fees to companies (like Verisign)
>because they need strong encryption.
In my experience (with a LOT of corporations), they instead use an
internal email system and give remote users access through an encrypted
virtual private network. This gives full LAN service, not just email.
------------------------------
** 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
******************************
