Cryptography-Digest Digest #366, Volume #13 Tue, 19 Dec 00 19:13:00 EST
Contents:
Re: Unguessable sequence of unique integers? (Tim Smith)
Re: Vendor software using CPU spin rate to generate random numbers (Steve Portly)
Re: does CA need the proof of acceptance of key binding ? (Anne & Lynn Wheeler)
Re: Vendor software using CPU spin rate to generate random numbers (Paul Rubin)
Re: Unguessable sequence of unique integers? (Bob Silverman)
Re: [Question] Generation of random keys ("Allan J. Heim")
Re: Vendor software using CPU spin rate to generate random numbers
([EMAIL PROTECTED])
Re: Steganography using text as carrier (Chris Gillespie)
Re: Steganography using text as carrier (Chris Gillespie)
Re: Vendor software using CPU spin rate to generate random numbers
([EMAIL PROTECTED])
Re: SMS security over various networks? (Chris Gillespie)
Re: Unguessable sequence of unique integers? ("Brian Gladman")
Re: In today´s paper I read how Cuban intelligence bosses are using shortwaves
and the Morse code to communicate with their intelligence agents in Miami ....
interesting .. when I was in California (I think) I got some strange messages to my
head .. (Joel Rubin)
Re: Steganography using text as carrier (Chris Gillespie)
Re: Protocol for computer go (David Hopwood)
Re: Steganography using text as carrier (Andre van Straaten)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tim Smith)
Subject: Re: Unguessable sequence of unique integers?
Date: 19 Dec 2000 12:51:24 -0800
Reply-To: Tim Smith <[EMAIL PROTECTED]>
On Tue, 12 Dec 2000 02:28:17 GMT, Bob Silverman <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>> I am looking for an algorithm for a generator of a sequence
>> of unique and unguessable 32-bit integers.
>> The number of integers created by the sequence must be
>> very large, i.e. in the 32-bit range and no two values
>> in the sequence must overlap until a fairly large number
>> (a minimum of 2^24 or so) of values have been found.
>
>Impossible.
....
>(2) Any truly random or pseudo random 32-bit sequence will have,
>with high probability a collision after 2^16 values. The probability
>of a collision after 2^20 is near certainty. Look up the
>birthday problem.
Note that he seems to have been careful to avoid asking for "random"
numbers, so I don't think your point #2 applies here.
--Tim Smith
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Vendor software using CPU spin rate to generate random numbers
Date: Tue, 19 Dec 2000 16:12:30 -0500
[EMAIL PROTECTED] wrote:
> Jeffrey W. Baker <[EMAIL PROTECTED]> wrote:
> > IMHO it would have been a better idea to use the system's random
> > capabilities, since some Unix systems now have very decent entropy
> > gathering algorithms. Is there some value to this algorithm that I am not
> > seeing?
>
> Is Mocha a java runtime environment? The name would seem to imply so.
>
> Anyway, the reason I ask is that the algorithm you describe sounds
> suspiciously like the random number generator in the java.security
> package. If that's the case, the problem is in the jdk itself, and not
> products built on it.
>
> --
> Matt Gauthier <[EMAIL PROTECTED]>
Here is an authoritative link.
http://www-106.ibm.com/developerworks/library/java2/
------------------------------
Subject: Re: does CA need the proof of acceptance of key binding ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 19 Dec 2000 21:17:57 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> I happened to have today a very short conversation with
> a person who apparently knows quite a lot about SET. She
> said that a bank has no absolute assurance that a claimed
> public key of its customer is indeed genuine (for there
> is no verification of identity). So the initial character
> of SET appears rather questionable to me. Maybe experts of
> the group would like to comment on this. Thanks.
there are all sorts of boundary & discontinuity conditions.
a person has an account number.
they need to get some bank characteristic and public key bound
together into a certificate. for the most part, that feature is not
being supported by the bank where the account is located.
a transaction is sign with a public key, the transaction is also (at
least) partially encrypted (especially the account number), the
transaction, an appended digital signature and a certificate is
transmitted to a merchant over the internet.
the merchant then does some stuff and transmits the transaction, the
digital signature and the certificate to an internet gateway.
the internet gateway uses the public key in the certificate to verify
the digital signature.
the internet gateway then generates an (iso) 8583 transaction turning
on the authenticated signature flag.
the transaction is then handled in the normal way.
.........
couple of notes ...
this is still a standard account number ... i.e. effectively a shared
secret that can also be used in vanilla, non-authenticated
transactions ... as a result there is significant exposure storing it
when it isn't "at rest" (i.e. both SET and SSL encrypt the number
while "in flight" ... but the big exposure when it leaves internet
transmission and actually is used in standard processes).
for retail transactions, identity is a serious privacy
issue. authentication wants to know that the entity authorized to
execute transaction against an account is the the entity executing the
transactions. divulging identity (aka an identity certificate) for
retail transactions represents a serious invasion of privacy ... and I
believe is also counter to current EU regulations (stating that all
retail transactions need to be as anonomous as cash ... aka even name
on existing cards and/or magstripes represents a serious privacy
problem). An identity certificate could represent even more serious
privacy problem that existing name embossed cards.
a couple years ago, one of the credit card associations presented
numbers at an ISO meeting of 8583 transactions flowing through the
network where the authenticated signature flag had been turned on
... but they knew there was no digital signature technology involved.
a couple sizings of standard SET certificates have put them in range
of 4kbytes to 12kbytes. a typical 8583 transaction is 60-100 bytes and
aggregate peak transaction loads can hit several thousand per second.
Actually flowing the SET certificate end-to-end on any real volume of
transactions represents a serious capacity problem (serious
transaction size bloat).
and of course, then there is X9.59 ... standard from the X9 financial
standards body ... the task given the X9A10 work group for X9.59 was
to preserve the integrity of the financial infrastructure for all
account-based retail transactions (credit, debit, card, ach, check,
etc). It has passed X9 and is entering its two year trial period.
X9.59 specifies an account number that can only be used in
authenticated transactions (eliminating the problem with the account
number being a shared secret representing significant fraud
exposure). X9.59 also recommends end-to-end authenticated transactions
(i.e. from beginning, entry-level security principles, i.e. the party responsible for
authorizing and executing the transaction is also responsible for authenticating the
transactions).
misc refs to x9.59 work
http://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], http://www.garlic.com/~lynn/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Vendor software using CPU spin rate to generate random numbers
Date: 19 Dec 2000 13:47:57 -0800
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> This code is in the weblogic.security package, class SpinnerThread,
> SpinnerRandomBitsSource, and others in the same package. In Weblogic
> 6.0, this class is zipped up in a jar file.
>
> This is the algorithm used in the jdk java.security package? Is it
> considered to be good enough in that role?
Yes, that's what java.security uses. I'd consider it questionable.
The comment in the source code basically says that it's questionable.
But I know that the Mindbright Java SSH implementation uses it too.
It's probably in the Weblogic jar file in case someone tries to
run Weblogic under a JDK that doesn't include the SecureRandom class.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Unguessable sequence of unique integers?
Date: Tue, 19 Dec 2000 21:40:41 GMT
In article <[EMAIL PROTECTED]>,
Tim Smith <[EMAIL PROTECTED]> wrote:
> On Tue, 12 Dec 2000 02:28:17 GMT, Bob Silverman <[EMAIL PROTECTED]>
wrote:
> >In article <[EMAIL PROTECTED]>,
> >> I am looking for an algorithm for a generator of a sequence
> >> of unique and unguessable 32-bit integers.
> >> The number of integers created by the sequence must be
> >> very large, i.e. in the 32-bit range and no two values
> >> in the sequence must overlap until a fairly large number
> >> (a minimum of 2^24 or so) of values have been found.
> >
> >Impossible.
> ....
> >(2) Any truly random or pseudo random 32-bit sequence will have,
> >with high probability a collision after 2^16 values. The probability
> >of a collision after 2^20 is near certainty. Look up the
> >birthday problem.
>
> Note that he seems to have been careful to avoid asking for "random"
> numbers, so I don't think your point #2 applies here.
Suppose one uses a keyed hash algorithm, keyed by a counter.
This will be sufficiently random to produce collisions after 2^16
values.
You need to do a lot of work to ensure that collisions do not occur
and this will generally make (the output of) your algorithm MORE
predictable.
--
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: "Allan J. Heim" <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Tue, 19 Dec 2000 14:20:26 -0800
Alan Rouse wrote:
> The hard part is knowing how much entropy you have collected.
> Perhaps you want to create a 160-bit key, so you need 160 bits
> of entropy. How can you be certain that you have that much?
> Tough question.
This is discussed in the Diceware FAQ:
http://world.std.com/~reinhold/dicewarefaq.html
--
Allan Heim
Sunnyvale, California
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Vendor software using CPU spin rate to generate random numbers
Date: Tue, 19 Dec 2000 22:33:37 GMT
In article <%8O%5.13$[EMAIL PROTECTED]>,
"Jeffrey W. Baker" <[EMAIL PROTECTED]> wrote:
> IMHO it would have been a better idea to use the system's random
> capabilities, since some Unix systems now have very decent entropy
> gathering algorithms. Is there some value to this algorithm that I
am not
Save your self the risk and the trouble and use a good TRNG instead.
Entrophy gathering on a deterministic machine is always risky.
--Mats S
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Tue, 19 Dec 2000 22:43:52 +0000
From: Chris Gillespie <[EMAIL PROTECTED]>
Subject: Re: Steganography using text as carrier
Mok-Kong Shen wrote:
> [EMAIL PROTECTED] wrote:
> >
> [snip]
> >
> > is there a way to hide already encrypted messages (ciphertext block)
> > within a *text* carrier,(not within the whitespace) and if so, what are
> > the size constraints of ciphertext to carrier text?
> >
> > as redundancy would not be particularly surprising in spam messages,
> > this might be a promising new avenue for effective steganography.
>
>
I suppose if the ciphertext were ascii-armoured you could use the Bacon
Bilateral method to hide the text in the message. Very small (hopefully
unnoticable) alterations in font could mark the ones and zeros. You'd need a
lot of text to hide the message in though....
Hope this helps,
Chris.
--
--
Chris Gillespie
Researcher
Dept of Computing
University of Bradford
email: [EMAIL PROTECTED]
------------------------------
Date: Tue, 19 Dec 2000 22:47:29 +0000
From: Chris Gillespie <[EMAIL PROTECTED]>
Subject: Re: Steganography using text as carrier
Chris Gillespie wrote:
>
> I suppose if the ciphertext were ascii-armoured you could use the Bacon
> Bilateral method to hide the text in the message.
Scratch that. The ciphertext wouldn't need to be ascii-armoured. Just use the
Bacon Bilateral method with visually unnoticable alterations to mark ones and
zeros.
--
--
Chris Gillespie
Researcher
Dept of Computing
University of Bradford
email: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Vendor software using CPU spin rate to generate random numbers
Date: Tue, 19 Dec 2000 22:59:51 GMT
Jeffrey W. Baker <[EMAIL PROTECTED]> wrote:
> This code is in the weblogic.security package, class SpinnerThread,
> SpinnerRandomBitsSource, and others in the same package. In Weblogic
> 6.0, this class is zipped up in a jar file.
> This is the algorithm used in the jdk java.security package? Is it
> considered to be good enough in that role?
Probably not exactly the same, but it follows the same basic outline
of the one in the jdk. That is, you described an algorithm so close to
the jdk that you'd need to hold them both up along side one another to
tell them apart. Which is why I assumed you may have reverse
engineered your way down into the java.security package.
As to being considered "good enough" that is, of course, a relative
term. The brutal truth is the thread-spinning algorithm wins by
default, there being no better way to generate random numbers. The
java.security version is the best approach (and is probably better
than what you describe) because:
1. A standard interface lets you use better facilities where
possible. For example, the Linux port of the jdk could actually read
/dev/random rather than sample threads.
2. You need to supply a default algorithm for platforms without
anything better. (So your java-enabled toaster can generate session
keys to communicate with your java-enabled coffee maker and coordinate
breakfast times)
So far, nobody's presented a way to predict the output of the jdk
one. It does, however, come with a warning that it may be
predictable. It's probably better than what most people cobble up
themselves, and less desireable than platform specific methods or
dedicated random hardware. Basically, it's the best of a bad lot.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
Date: Tue, 19 Dec 2000 23:16:42 +0000
From: Chris Gillespie <[EMAIL PROTECTED]>
Subject: Re: SMS security over various networks?
Chris Kantarjiev wrote:
> I'm trying to put together a white paper on the relative merits of text
> messaging security via SMS over the various cell networks: CDMA, GSM,
> AT&T's TDMA.
>
> I've found a number of links about voice security, but they're mostly
> fluff, and they never really mention whether the same
> algorithms/techniques apply to SMS when sent over the network.
>
> I can find references, for example, to A5 for GSM, and A5 having been
> broken, but no clear information about how A5 is or isn't used for SMS
> (as opposed to voice).
>
HA HA HA!! Sorry to skew off the point guys, but I've just
been looking into GSM encryption for this question, and
Applied Cryptography says it was my University that leaked
the details of the A5 algorithm. I don't know if I shoud
be proud or ashamed....
Chris.
--
--
Chris Gillespie
Researcher
Dept of Computing
University of Bradford
email: [EMAIL PROTECTED]
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Unguessable sequence of unique integers?
Date: Tue, 19 Dec 2000 23:27:45 -0000
"Bob Silverman" <[EMAIL PROTECTED]> wrote in message
news:91okko$je4$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Tim Smith <[EMAIL PROTECTED]> wrote:
> > On Tue, 12 Dec 2000 02:28:17 GMT, Bob Silverman <[EMAIL PROTECTED]>
> wrote:
> > >In article <[EMAIL PROTECTED]>,
> > >> I am looking for an algorithm for a generator of a sequence
> > >> of unique and unguessable 32-bit integers.
> > >> The number of integers created by the sequence must be
> > >> very large, i.e. in the 32-bit range and no two values
> > >> in the sequence must overlap until a fairly large number
> > >> (a minimum of 2^24 or so) of values have been found.
> > >
> > >Impossible.
> > ....
> > >(2) Any truly random or pseudo random 32-bit sequence will have,
> > >with high probability a collision after 2^16 values. The probability
> > >of a collision after 2^20 is near certainty. Look up the
> > >birthday problem.
> >
> > Note that he seems to have been careful to avoid asking for "random"
> > numbers, so I don't think your point #2 applies here.
>
> Suppose one uses a keyed hash algorithm, keyed by a counter.
>
> This will be sufficiently random to produce collisions after 2^16
> values.
>
> You need to do a lot of work to ensure that collisions do not occur
> and this will generally make (the output of) your algorithm MORE
> predictable.
What concerns do you have about a counter (or any other regular sequence
generator) encrypted with a suitably chosen cipher to meet this requirement?
Given a suitably long key this seems to work - are there problems we should
worry about when ciphers are used as permutation generators?
Brian Gladman
------------------------------
From: Joel Rubin <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.security,comp.security
Subject: Re: In today´s paper I read how Cuban intelligence bosses are using
shortwaves and the Morse code to communicate with their intelligence agents in
Miami .... interesting .. when I was in California (I think) I got some strange
messages to my head ..
Date: Tue, 19 Dec 2000 18:25:57 -0500
Actually what there are (and I believe these are still used in 2000 by
Cuban intelligence) are "numbers stations" which read strings of
numbers in English and/or Spanish. These are presumed to use some sort
of one-time pad system.
If you really want to find out about them do a web search or ask on
say rec.radio.shortwave.
------------------------------
Date: Tue, 19 Dec 2000 23:33:58 +0000
From: Chris Gillespie <[EMAIL PROTECTED]>
Subject: Re: Steganography using text as carrier
Oh yeah, does anyone have any idea how the algorithm for the spam mail works?
--
--
Chris Gillespie
Researcher
Dept of Computing
University of Bradford
email: [EMAIL PROTECTED]
------------------------------
Date: Tue, 19 Dec 2000 23:27:28 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Protocol for computer go
=====BEGIN PGP SIGNED MESSAGE=====
Francois Grieu wrote:
> [EMAIL PROTECTED] wrote :
> > 2. For each move, the current player publishes its move, and then
> > someone (it doesn't really matter who) publishes a timestamp,
> > which is the elapsed time since the start of the game. Both
> > players and any observers check that this timestamp is
> > approximately correct.
> > A player's move is required to be a deterministic function (which
> > is calculated by the replay program) of all previous moves and
> > their timestamps.
>
> At least one change is needed:
> A player's move is required to be a deterministic function
> (which is calculated by the replay program) of some previous
> moves and timestamps, as follow:
> let T(j) be the timestamp for the jth half-move in the game,
> with first with half-move 1. Replay program shall be [fed]
> with T(j+1)-T(j) for odd j if it moves first, for even j
> if it moves second. This information should be made
> available to the replay program by the referee, after the
> replay program has announced half-move j, together with the
> opponent's half move j+1.
>
> Without such precaution, a human can influence the speed of the
> play program and easily pass information to the replay program.
Good point - the time taken by a player's previous moves acts
as a covert channel. Having the referee choose and publish the
timestamp would reduce the bandwidth of this channel, but not
eliminate it (and so is not sufficient). I think your proposed
solution is reasonable, with the modification I suggest below.
> Great care should be taken by the referee that no extra bit of
> information can reach the replay program: moves and delta of
> timestamps shall be in an unambiguous format. Since the programmer
> can probably choose the moment of the replay to some extend, the
> replay program shall not be allowed to know this information, nor
> the date/time information for the (hash-protected content) zip
> file the replay program came from, and a fortiori not the log
> file.
That's an interesting point that applies more generally; idealised
descriptions of protocols rarely model anything about messages
other than their contents and ordering. It's fortunate that
most cryptographic protocols don't depend on eliminating side
channels!
> It should be stressed that even a single bit of side channel
> (like and attack/defend hint in the midgame) is of considerable
> practical value.
>
> Even with all these precautions, the timestamps still leave some
> room for side channel: for example if the adversary makes good
> use of the program's thinking time, T(j+1)-T(j) [known to the
> replay program] tends to be low when T(j)-T(j-1) [chosen easily
> by a human] is high.
Making sure that T(j)-T(j-1) is a deterministic function of the
previous moves, and the time that the opponent took to make its
moves, should fix this.
> I think this side channel could be closed by requiring the replay
> program not only to tell its move, but also when in the log it
> must be. That is, the replay program should announce the value
> T(j)-T(j-1) together with half-move j.
Yes, that's the same conclusion I reached. More precisely, both
the play and replay programs should output T(j)-T(j-1) as an
estimated time, which must be larger than the actual time taken for
that player to send (move(j), T(j)-T(j-1)) to the referee. If the
player is not able to make its move within the time estimate, it
is deemed to have cheated, and loses the game. If it publishes
the move before time, the opponent's clock does not start until
time T(j). This gives the opponent extra thinking time on the
current player's clock, and therefore there is an incentive to
make the estimates as close as possible.
> Then there is the issue of precision. What if the replay program
> is off-by-one ?
I think this is solved by the method above. It is quite easy to
compute the time taken by the algorithm if it can be a slight
overestimate (e.g. using the instrumented compiler approach I
suggested earlier).
> Another potential side channel is with with network tricks to
> infuence the timestamps slightly (say making T(j+1)-T(j)
> even or odd).
Influencing the length of time the opponent's move takes to be
published, you mean? Probably the two players should be on separate
(physically isolated) networks.
> Maybe the sad the conclusion is that the single most practical
> thing is to disallow program to be influenced by time at all.
No, I think we've pretty much solved this now, unless anyone can
find another attack.
- --
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
iQEVAwUBOj8UWTkCAxeYt5gVAQFdeAgAqwbUAiLSYJV1lYSW+3uhMaLQ1UnhAYaC
gsYRgYY8wmwgGFW/+OuU8pmoTKJkARt1mH0kFj97VpfyDwdhmwUxPL0HGwQOoXFb
3G3A9lk6MDTsrh54LQEVcMrqzDexYhz2+xMNBYjhGohSCBdpGihbNjKSRtEIDeEp
i29inlNDKkknC/4zzPaq/BdqQRTA1u5OYL5FxMzD+b05JSbHDoOWC3Lno9iy1Vsd
3BYiNL9+q5+TG7y2taemy/nkYuoWzugasep/DUdj2d8sbnTfP8qmDgsbUKAwDlni
m6Ro4+ByWPVwAgiXzCQ5w1b82Bp6ZdLbyqS8hft5eY3EjwzznrqE+A==
=ewP9
=====END PGP SIGNATURE=====
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Steganography using text as carrier
Date: 19 Dec 2000 17:28:28 -0600
[EMAIL PROTECTED] wrote:
> found an interesting site that wants to steganographically hide text
> messages within spam messages:
> http://www.spammimic.com
> the site admits that the encryption is weak, and relies on the natural
> aversion to spam and reflex deletion of the spam message
If someone shadows a particular person, it might be suspicious that
this person starts sending spam when he/she doesn't have an appropriate
business (mail/Web order, MLM, etc.).
> is there a way to hide already encrypted messages (ciphertext block)
> within a *text* carrier,(not within the whitespace) and if so, what are
> the size constraints of ciphertext to carrier text?
There is a book:
Peter Wayner, Disappearing Cryptography, AP Professional, 1996,
which I bought at www.bookpool.com
I've read only the first chapters about messaging via error-correcting
codes, but the main part is about generating and altering ASCII text.
> as redundancy would not be particularly surprising in spam messages,
> this might be a promising new avenue for effective steganography.
I don't think it's a good idea to use spam messages, as this is
something very suspicious.
Or is anyone in this NG here sending frequently spam?
For the Usenet, I would rather rely on unqualified comments, what
I'm doing from time to time, or others, too, I think on some recent
discussions about English grammar in sci.crypt.
Spelling errors are very useful, similar to hiding errors in messages
with error-correcting codes.
For e-mail, interchange buggy program source code or lengthy
documents.
> thanks in advance for any information or references
> vedaal
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
The signs and the omens are everywhere
But too few see them - too few even care
(Lee Clayton - singer/songwriter, 1979)
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
** 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
******************************
