Cryptography-Digest Digest #512, Volume #14 Mon, 4 Jun 01 07:13:01 EDT
Contents:
Sv: Top Secret Crypto ("Peter Nielsen")
about DH parameters & germain primes (quequ)
Re: Def'n of bijection (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: benefits of compression for security (Ian Stirling)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
----------------------------------------------------------------------------
Reply-To: "Peter Nielsen" <[EMAIL PROTECTED]>
From: "Peter Nielsen" <[EMAIL PROTECTED]>
Subject: Sv: Top Secret Crypto
Date: Mon, 4 Jun 2001 11:09:41 +0200
I have read this in the instruction to the program. What is your opinion
about this ?. That is what have convinced me that it is a good program.
Regards
Peter Nielsen.
The Random Bits Bin - A True Source of Random Bits
The Random Bits Bin is a file called RandomBitsBin.rbb that is created and
maintained by Top Secret Crypto. It is 8,192 bytes, or 65,536 bits, long,
and once it is read into memory, it is constantly being changed by Top
Secret Crypto. Any time a seed, key, or numeric value, such as Prime p or q,
is required by Top Secret Crypto, it is extracted from somewhere within the
Random Bits Bin. When you exit the program, the RandomBitsBin.rbb file is
updated with the current contents of the Random Bits Bin in memory, thus
creating a new RandomBitsBin.rbb file for the next time you use Top Secret
Crypto.
The big question everyone is asking themselves right now is, how can a
computer be a source of random bits?
Every computer has a system timer. In the case of most Intel® computers, it
beats with a frequency of 1.193 million times per second. This system timer,
or high resolution performance timer, can be read by any computer program.
Top Secret Crypto sets up, and runs, a separate thread whose sole function
is to read the system timer and update the Random Bits Bin. Since the thread
does not have control all the time, there is no way of predicting the value
in the system timer when the thread does get control. The first time the
system timer is read, its low 8 bits are XNORed with the first 8 bits of the
Random Bits Bin. The next time it is read, the next 8 bits are XNORed with
the low 8 bits of the system timer. When you reach the end of the Random
Bits Bin, you start over at the beginning.
Due to the speed of the computer, the entire contents of the Random Bits Bin
may change many thousands of times per second. To prove my point, fire up
Top Secret Crypto and let it run for only a second or two. Take a look at
the contents of the RandomBitsBin.rbb file and you will see how random the
data in it is.
Initial Conditions - Or How to Tell a Good Encryption Formula
Most pseudo random number generators can produce a long string of random
numbers, or characters, to encrypt a file with. What we want to determine is
what makes a good pseudo random number generator, or another way to put it
is what pseudo random number generator makes a good encryption formula.
A complex encryption formula seems like a good idea. But that is forgetting
one of the basic rules of cryptography: The General System is known - to
everyone. If you buy a commercial encryption program that is sold over the
counter, you have the general system for that product. You do not even have
to understand its complex encryption process. The program does it all for
you. DES has a very complicated encryption formula, but only a 56-bit key.
It can be broken with ease. It also burns up computer cycles and takes a
long time, relatively, to encrypt or decrypt a file.
The only thing left is the seed, key, or what I call the Initial Conditions
that start the pseudo random number generator in the encryption formula
going. The larger the number of seeds that can start an encryption formula,
the better. DES with its 56-bit key is no good. 2 to the 56th power equals
7.205 times 10 to the 16th power. PGPT uses the IdealT Encryption Formula,
which uses a 128-bit key. 2 to the 128th power equals 3.402 times 10 to the
38th power. It you believe Tom Clancy in Rainbow Six this is not even good
enough any more. Depending on the size of the smallest RSA Key used, Top
Secret Crypto will seed 4, 8, 16, 32, or 64 random number generators, which
require 325-353, 613-669, 1189-1301, 2341-2565, or 4645-5093 random bits as
the key, when sending an encrypted file to multiple recipients. As long as
the NSA cannot break the RSA Public Key Encryption System, these key sizes
should be sufficient. But in case they are not...
This is why Top Secret Crypto includes a second method for seeding its
pseudo random number generators, or encryption formula. It can create One
Time Pad (OTP) Key Files, each of which contains 1,303 randomly generated
numbers in the range 100,000,001 to 4,294,967,295. Each number is 32 bits
long. From the 1,303 random numbers in an OTP Key file, 768 numbers are
randomly selected to seed the 256 pseudo random number generators used in
the encryption process. 512 of the 768 random numbers use the full 32 bits
for 16,384 bits. The other 256 are shifted right by a factor of 17 to 24
leaving 8 to 15 bits. This gives you 2,048 to 3,840 more bits. Add in 37
more for an initial seed and random factor array shift valve for a final
total of somewhere between 18,469 and 20,261 bits used as the Initial
Condition for the 256 pseudo random number generators. This is a number
between 2 to the 18,469th power and 2 to the 20,261st power. Using
logarithms, this works out to a number between 5.284 times 10 to the 5,559th
power and 1.474 times 10 to the 6,099th power.
For anyone to duplicate this string of 18,469 to 20,261 bits from an OTP Key
file without the original file would require a miracle in the absolute true
sense of the word. Not knowing exactly how many bits are used each time you
encrypt a file is another hurdle for the would be cryptanalyst to overcome
when trying to decrypt the file.
The One Time Pad Encryption System
It was first developed in America in 1918, completely rejected by the U.S.
Government, and first used by the German diplomatic establishment sometime
between 1921 and 1923. It is called the One Time Pad System. It is a
remarkable system in its simplicity. For further information see pages 398
to 400 of the hardback edition of The CODEBREAKERS by David Kahn, published
by The Macmillan Company in 1967. It consists of a random key used once, and
only once. It provides a new and unpredictable key character for each
plaintext character in the message. This means that every letter or
character is enciphered with its own random key. The letter A may be
enciphered into a Z the first time it is encountered in the message and into
an N the next time, a B the next, and so on and so on. This means for a
message that is enciphered as Z T Q W the first Z could be deciphered into
any of the 26 letters of the alphabet. This holds true for all the other
letters also. This could be deciphered into the word L O O K where both the
T and the Q stand for the letter O.
I quote: "And it is an unbreakable system. Some systems are unbreakable in
practice only, because the cryptanalyst can conceive of ways of solving them
if he had enough time. The one-time system is unbreakable both in theory and
practice. No matter how much text a cryptanalyst had available in it, or how
much time he had to work on it, he could never solve it."
I quote again: "The perfect randomness of the one-time system nullifies any
horizontal, or lengthwise, cohesion, as in coherent running key or autokey,
and its one-time nature bars any vertical assembly in Kasiski or Kerckhoffs
columns, as in keys repeated in a single message or among several messages.
The cryptanalyst is blocked."
If you were to use the brute force method and try to decipher this message
with every possible key combination all you would have done is compile a
list of every possible four letter word in the world. There are stop, hard,
slow, kiss, etc., etc., etc. The longer the message the more possibilities
there are. What it boils down to is that you have an equation in two
unknowns with only 1 equation, and that is impossible to solve. X + Y = 9.
You know that 9 is the ciphertext. Without another equation there is no way
to solve X (the plaintext) or Y (the key). X and Y could be any values you
choose that equal 9. All this does is compile a long list of possible
solutions with one just as good as the other. Since there are an infinite
number of numbers there are an infinite number of solutions to the above
equation. One could be just as valid as the other. There is no way to know
which one is right.
In this age of computers why is this One Time Pad System not in widespread
use? Could it be the fact that computers cannot generate random numbers. All
they can generate is pseudo-random numbers. This means that the string of
random numbers produced by one computer can be reproduced by that or another
computer using the same formula. But this is exactly what is required by any
computer program to encipher data. You need to be able to reproduce that
same set of random numbers to decipher the data.
There are many formulas to generate pseudo-random numbers on computers. But
even this is not enough. Most of these formulas only require a small seed
number to get the formula going. This is the key to why these formulas and
other encryption formulas are no good. Remember this:
NO MATTER HOW INTRICATE OR COMPLEX ANY DATA ENCRYPTION FORMULA IS, IF THE
SEED NUMBER TO START THE FORMULA IS SMALL, THAT ENCRYPTION FORMULA CAN BE
VERY EASILY CRACKED BY THE BRUTE FORCE METHOD.
Just plug in all possible seed numbers into the formula using a super
computer and within a matter of hours any message can be decoded. This is
the bane of most encryption formulas. They try to keep the seed number small
by using very complex and lengthy formulas because human beings, you and me,
do not like to enter 100 and 200 digit seed numbers into a computer every
time we have to encipher or decipher a message. The small seed number is
their Achilles Heel.
To see how Top Secret Crypto gets around this problem see Initial
Conditions - Or How to Tell a Good Encryption Formula.
The key to being true to the One Time Pad Encryption System is to always use
One Time Pad Key Files to encrypt your files, and to use a One Time Pad Key
File only once. This ensures that every enciphered message will have a
unique key, which means a unique string of pseudo random characters that is
just as long as the file. If you follow this simple rule, any message that
is intercepted will not be able to be broken or analyzed in any way.
While this may prove a little inconvenient at times, especially if two
people live on opposite sides of the world, it is the only way to ensure
that your encrypted data is 100% safe.
Top Secret Crypto provides a method of generating hundreds, or thousands, of
One Time Pad Key Files at one setting, on a hard drive, a floppy disk, or CD
you can write to, so two people do not have to constantly exchange One Time
Pad Key Files with all the risks that this entails. See Tips on Using Top
Secret Crypto in the Real World for some ideas on how to accomplish this.
------------------------------
From: quequ <[EMAIL PROTECTED]>
Subject: about DH parameters & germain primes
Date: Mon, 4 Jun 2001 11:31:37 +0200
Hi, I've found this tip about Diffie-Hellman parameters:
"If p, (p-1)/2 both prime, then you can just use any
g you please [other than 0, 1, and -1], and you'll
get a very large order [at least (p-1)/2]"
It's right?
I've tried a 1024bit germain prime P and the generator G set to (P-1)/2.
Are these good parameters?
thanks to all
quequ
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Mon, 4 Jun 2001 10:24:16 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Nicol So" <[EMAIL PROTECTED]> wrote in message
:> :> Tom St Denis wrote:
:> :> > That means it's invertible and closed right (i.e from set A to set B,
:> :> > A=B)?
:> :>
:> :> Invertible? yes. Domain = range? No.
:>
:> : It said "all bijections have a function f' such that f'(f(x)) = x" and
:> : "for every element of the codomain there is some element of the domain which
:> : maps to it"
:>
:> : This means in the case of TimTyler's argument about 1 byte => 3 byte is
:> : a bijection [...]
:>
:> You'd better quote what I actually said if you're going to do this.
:>
:> A /particular/ one-byte value mapped to a three byte value in the
:> bijection I was discussing.
[...]
: Scott said that he could make a compressor where inputs mapped to outputs of
: different length (i.e 1 => 3). This would mean that all 3's must map to 1
: bytes. Violation of terms.
: He should have said some of the 3 bytes goto 1 byte (i.e 256 of them) and
: the other 3 byte messages map to other lengths...
David Scott posted the following correct statements:
DS>If you encrypt one byte with BICOM you most likely will
DS>get several bytes out. However if you did get one byte
DS>out the input file could be far more than one byte. This
DS>is beacuse if the key is not known many many thousands of
DS>different possible input files could have mapped to that
DS>single one byte output file.''
..and...
DS>And you never anwsered the FACT that a one byte ouput file
DS>from CTR mode (though you have no working program) would imediately
DS>lead an attacker to realize that the input file could only have
DS>come from 1 of 256 possible messages. With BICOM you have many
DS>many more messages. That alone makes it more secure.''
I wrote:
TSD>Let's say a 1 byte file maps to 3 bytes.
TT>OK.
TSD>Now to be fully bijective you must map all 3 byte files to 1 byte.
TT>A false statement on your part - bijectivity in no way requires such a
TT>map to exist. Want to try again?
While you wrote:
TSD>Now to be fully bijective you must map all 3 byte files to 1 byte.
TT>A false statement on your part - bijectivity in no way requires such
TT>a map to exist. Want to try again?
TSD>Um wrong. A bijection is where the domain and range are the same
TSD>set.[...]
So it turns out that you are arguing with us because you don't know what a
bijection is. I wish I had known that a long time ago.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 4 Jun 2001 10:27:29 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :[D. Scott wrote:]
:> :> If you encrypt one byte with BICOM you most likely will
:> :> get several bytes out. However if you did get one byte
:> :> out the input file could be far more than one byte. This
:> :> is beacuse if the key is not known many many thousands of
:> :> different possible input files could have mapped to that
:> :> single one byte output file.
:>
:> : Ok bud, there is more to the world than "encryption". BICOM as I
:> : pointed out earlier is vastly inefficient as compared to CTR modes
:> : and as you have failed to point out not any more secure.
:>
:> He explained it - you just didn't understand the explanation.
: What explanation? All he does is flame me.
This sort of thing, repeated several times now:
DS> And you never anwsered the FACT that a one byte ouput file
DS> from CTR mode (though you have no working program) would imediately
DS> lead an attacker to realize that the input file could only have
DS> come from 1 of 256 possible messages. With BICOM you have many
DS> many more messages. That alone makes it more secure. [...]
:> : Now to be fully bijective you must map all 3 byte files to 1 byte.
:>
:> A false statement on your part - bijectivity in no way requires such a map
:> to exist. Want to try again?
: Um wrong. A bijection is where the domain and range are the same set.
So you don't know what a bijection is? Ah...
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Ian Stirling <[EMAIL PROTECTED]>
Subject: Re: benefits of compression for security
Date: Mon, 04 Jun 2001 10:37:11 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
<snip discussion on role of compression in crypto, and drawbacks.>
>Problem is nobody wants to use pre-built dictionaries for general purpose
>codecs. They are not ideal.
What about simply reversing the file?
Obviously, this does imply needing storage equal to either the filesize,
or the block size, and needs some care about the end to get all the
bytes out.
--
http://inquisitor.i.am/ | mailto:[EMAIL PROTECTED] | Ian Stirling.
===========================+=========================+==========================
"Give a man a fire, and he's warm for a day. Set him on fire, and he's warm
for the rest of his life" -- Terry Pratchett-Jingo
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 4 Jun 2001 10:32:19 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
:D.Scott:
:> In BICOM there are 2**256 differnt F's one for each key,
: Or, in other words, BICOM is a keyed set of 2**256 bijections. Not really a
: crucial distinction, however, you're been stating so long that BICOM is a
: bijection that I assumed it was unkeyed.
BICOM (for BIjective COMpressor) can optionally have its output fed
through Rijndael (which is built into it). You can use it in either
keyed or unkeyed mode. Whichever mode you use it in, the result is
a bijection from the set of all 8-bit granular files to the same set.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 4 Jun 2001 10:36:25 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : a 8-bit message can only map to 8-bit outputs to be bijective (well
:> : not entirely).
:>
:> Not at all in fact. Do you realise how wrong that is?
:>
:> : CTR mode is just a bloody xor of some random bits against a
:> : message. How can that possibly be less secure than BICOM?
:>
:> To repeat David Scott's example, consider a 1 byte cyphertext message.
:>
:> In CTR mode it maps to one of 256 possible plaintexts.
:>
:> With BICOM it maps to one of *billions* of possible messages.
:>
:> You tell me which is more likely to be secure.
: But an OTP is provably secure so your question is moot.
Actually, if you use an OTP in the same way that you use CTR mode -
i.e. you chop off any cyphertext beyond the end of the message -
the cyphertext in an OTP system leaks length information about the
plaintext - and consequently fails to have Shannon's "perfect
secrecy" property.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Mon, 04 Jun 2001 10:52:13 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> : But an OTP is provably secure so your question is moot.
>
> Actually, if you use an OTP in the same way that you use CTR mode -
> i.e. you chop off any cyphertext beyond the end of the message -
> the cyphertext in an OTP system leaks length information about the
> plaintext - and consequently fails to have Shannon's "perfect
> secrecy" property.
"Chop off any cyphertext beyond the end"?
What does that mean? I hate to burst your bubble but an OTP is provably
secure so you might as well not argue this with me.
> --
> __________
> |im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Mon, 04 Jun 2001 10:53:29 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
> :> :[D. Scott wrote:]
>
> :> :> If you encrypt one byte with BICOM you most likely will
> :> :> get several bytes out. However if you did get one byte
> :> :> out the input file could be far more than one byte. This
> :> :> is beacuse if the key is not known many many thousands of
> :> :> different possible input files could have mapped to that
> :> :> single one byte output file.
> :>
> :> : Ok bud, there is more to the world than "encryption". BICOM as I
> :> : pointed out earlier is vastly inefficient as compared to CTR modes
> :> : and as you have failed to point out not any more secure.
> :>
> :> He explained it - you just didn't understand the explanation.
>
> : What explanation? All he does is flame me.
>
> This sort of thing, repeated several times now:
>
> DS> And you never anwsered the FACT that a one byte ouput file
> DS> from CTR mode (though you have no working program) would imediately
> DS> lead an attacker to realize that the input file could only have
> DS> come from 1 of 256 possible messages. With BICOM you have many
> DS> many more messages. That alone makes it more secure. [...]
I have a cipher that uses 3-bit sboxes, that alone makes it more secure....
His logic is flawed. He states a feature of BICOM then assumes its a
security bonus.
Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 4 Jun 2001 10:58:45 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Roger Fleming <[EMAIL PROTECTED]> wrote:
:> : [EMAIL PROTECTED] wrote:
:> Ensuring good key diffusion may become more computationally
:> demanding, but it can be done using a simple hash function - I
:> wouldn't say there was anything especially dificult about it.
:>
:> There may be a computational cost - but it's only going to affect key
:> agility, not encryption/decryption throughput.
: Using hashes as part of your cipher design is typically the sign of an
: amateur.
That was an example of how to do it simply - not an example of how
to do it efficiently. Getting diffusion across a whole key is not
rocket science - but it /can/ be computationally expensive, relative
to the effort necessary with smaller keys.
:> : 3. Transmission and storage of such keys is a serious problem. The
:> : whole point of ciphers is that a large secret (the message) can be
:> : protected by a small secret (the key).
:>
:> Hmm. Some would say that the whole point of cyphers is protecting the
:> message, and it doesn't matter how you do it.
:>
:> If you exchanges a huge key when you met in person last week, I don't see
:> any good reason not to take advantage of it.
: Again I will introduce you to reality. The whole point of cyphers [sic] is
: not just protecting the message. It's filling out Maslows Triangle of
: needs, it's being buzzword compliant. Which are often more important.
Protecting a large secret with a smaller one is not the "whole point of
cyphers". Protecting messages may not be either - but at least it comes
closer to the truth. I'll leave the buzzwords to you.
:> :>that keys much bigher the 128 bits are useless overkill?
:> :>Key distribution is indeed a problem - but I don't think anyone could
:> :>convinvingly argue that 128 bits is enough and more is pointless.
:>
:> : OK, I will attempt to convincingly argue that 128 bits is (nearly
:> : always) enough and more is (usually) pointless - for a few decades,
:> : anyway.
:>
:> Hmm. This is what I was afraid of. Trusting that one's cypher's won't be
:> broken is not something that everyone is prepared to do.
: Cough, cough. AES.
If AES is widely used it will be a demonstration of how a large number of
people are prepared to put their trust in a single cypher. Only the dim
distant future will let us know whether this trust was well placed.
The last time this happened was with DES. Many people would up using DES
- but it is now seen as being not very secure, and DES-cracking machines
exist.
Anyway, trusting that one's cypher's won't be broken is not something that
everyone is prepared to do - and the mere possibility of things like
quantum computers being built in secret to crack AES messages rapidly will
be enough to deter some people from using it.
I am not alone in being distasteful of the idea of picking one algorithm
and sticking to it. In the past, rapidly changing cypher algorithms have
been employed, to present a moving target to analysts. In modern times,
folks like Terry Ritter keep this idea alive, by advocating the used of
dynamically-negotiated cypher stacks.
:> :>AFAICS, allowing variable size keys is not terribly painful in terms
:> :>of fattening up the key schedule. It seems like a good idea to me.
:>
:> : It can be a good idea if it is done carefully, but most algorithms that
:> : get it right seem to use very slow, complex key schedules that limit
:> : their utility for some purposes.
:>
:> Hmm. If fed a short key, I see no good reason for such a key schedule to
:> be any slower than normal.
:>
:> Large keys have their cost in terms of key schedule, I'd agree - but then
:> again, the results are more likely to be secure.
: Not true. Using a bigger key doesn't always make the result more secure.
That's why I used "more likely" rather than "definitely going to be".
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
** 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
******************************
