home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Current Shareware 1994 January
/
SHAR194.ISO
/
virus
/
strng25.zip
/
STRNG25.DOC
< prev
next >
Wrap
Text File
|
1993-08-15
|
26KB
|
501 lines
-----------------> ATTENTION <-----------------
YOU MUST READ THIS SECTION BEFORE PROCEEDING TO USE THIS PROGRAM
You use the program at your own risk.
Since we do not have any control over the use of this program, we
will not be held responsible for any costs, time, or any other losses
which you may incur as a result of your use of this program. Due to
the nature of this program we cannot give any warranty of suitability
for any purpose, and we thus cannot offer any warranty including that
of merchantability.
Your only remedy is a refund of the purchase price from the vendor
you purchased it from. ( and since this program is provided to the
non-commercial and non-governmental public at no cost.....)
You are specifically prohibited from the use of this program for any
purpose that is contrary to applicable laws or regulations, and this
program must not be used for any such purpose.
Any commercial, or governmental, use of this program, including
investigation of the algorithm(s) incorporated within it, must be
disclosed to, and negotiated with, the author prior to such use.
If you cannot agree to the above, then don't use this program.
S/W Consultants
San Ramon, California 94583
S / W Consultants Can Be Reached On
Genie: L. WEINMAN
Compuserve: 76530,1142
Internet : 76530.1142@compuserve.com
L.WEINMAN@genie.geis.com
-----------------------------------------------------------------
-----------------------------------------------------------------
Hello, and Welcome to StrangeCryp V 2.5
A program for data security.
__________________________________________________________________
Note: When we speak of keys in this document, or program, we may be
referring to either the keys that the users enter as their "key" to
the encryption, or to the generated sequence that serves as the
encryption "key" for the data. The meaning should be clear from the
context.
First, we should give a very brief lesson in data security.
There are only two ways in which data may be kept secure against
unwanted dissemination:
1. Do not allow the data to fall into unwanted hands.
2. Do not keep, or transmit, the data in a form which will be
intelligible to anyone who you have not authorized to read it.
Simple, isn't it?
As a matter of fact there is a fairly large industry, plus
governmental departments devoted to this problem. The first way
leads to safes, guards, armored vans, and endless problems for an
individual or small business. Even with all of these precautions, the
security of the data may be comprimised.
StrangeCryp provides the following:
1. Very long encryption keys, or sequences.
2. Very many different key sequences.
3. Facilities to encrypt a file to printable text.
4. A complex running block transposition / substitution algorithm.
5. Available source code so you can judge the strength of the system.
Known Disadvantages:
This program utilizes a secret key that must be kept secret, and is
definiteley not as fast as DES.
Data Encryption.
Over the past 2000 years or so, many different schemes have been
proposed to accomplish this. There is even a method named after
Julius Caesar, who is supposed to have invented it. Most of the
older methods involved substitutions and transpositions based on a
relatively small key and some, more or less complex, algorithm to
accomplish the encryption. Relatively recently the United States
Government Bureau of Standards contracted IBM to develop the Data
Encryption Standard or DES, and proposed that it be utilized for all
private commercial encryption. Interestingly, however, the
Government does not allow classified data relating to national
security to be so encrypted, unless it is also kept physically
secure. If it is kept physically secure it does not have to be
encrypted. There has been more than a bit of speculation that data
encrypted with the DES can be decrypted by the National Security
Agency, and perhaps others. More recently your friends in the
Government have proposed the "Clipper" encryption chip - with a
secret algorithm known only to them. You may reach your own
conclusion.
There does exist, however, a system that is the ultimate in security.
That system is the "one time", the invention of which has been
attributed to Joseph Mauborgne of the United States Signal Corps. This
method involves the use of a different pseudorandom key to encrypt
each character of data. Since there is no short repetative key
involved, there is no method to decrypt the data without having
access to the key that was used to encrypt it. Provided, however, the
sequence, or key, is approximately as long as the data to be
encrypted, and is suitably random in nature. At the time, the problem
of generating large quantities of random numbers presented a major
problem. The large quantities are needed because if the sequence of
random numbers is too short and repeats during the data length, the
encrypted data becomes subject to analysis and decryption. As you
might suspect, an embassy, or military base might easily have to
encrypt many tens or even hundreds of thousands of characters a day.
Many random numbers are needed.
When we speak of random numbers, what we really mean is pseudorandom
numbers, or, a sequence of properly distributed apparently random
numbers that may be duplicated when required. For security reasons,
we also would like many different sequences available, so that
different messages, or compilations of data, may be encrypted with
different keys.
Cryptanalysis, or decryption by someone not authorized by the
encryptor, is accomplished by examining the distribution(s) for
different items in the set of encrypted data. StrangeCryp operates
by joining the set representing the plain data and a set of
pseudo-random numbers. Provided that the set of pseudo-random numbers
exhibits no detectable pattern (is suitably random), is reasonably
uniformly distributed, and is of size equal to the size of the data
to be encrypted, there is no feasible way to recover the original
data from the encrypted data without the key(s). A little thought
will confirm this. If any letter could be any other letter, with no
way to determine any probablity distribution, then the message "SEND
ME MONEY" could be intrepreted as "GIVE ME HONEY", or equally, "LEND
ME SONNY". In this example the word "ME" and the spacing was
deliberately shown the same in each case, but the message could also
be "KILL BASTARDS" or "LOVES MOTHERS" since the ASCII character for a
space may also be encrypted, and each message contains the same
number of characters.
One of the strong points of the StrangeCryp program is the large
number of different key sets that are available: probably in excess
of 10^100. Or put another way, if someone were to test one hundred
billion keys per second ( at present very unlikely), it would still
take about a hundred zillion years to test them all. This sort of
thing, in itself, discourages any thought of even attempting key
exhaustion as a means of cryptanalysis on data known to be so
encrypted. And, at the present time, even for a "known plaintext
attack" there has not been an analytic method published for the
recovery of the key file.
Instructions for use:
Installation:
Hardware:
No special hardware is required, except for reasonable IBM
compatability. However, if you do not have a VGA or EGA Adapter , you
will not be able to graph the distribution of the encryption key
stream. The program has been tested on a "vanilla 8 Mhz 286 clone",
and the equivalents in 386 and 486. The resulting data files were
compatible. The 286 ran acceptably, the faster machines would allow
faster operation. Earlier versions utilized an 80x87 chip if it was
available. This sometimes caused a compatability problem with various
machines with and without the chip. This version does all the
computation in software. Although it is a bit slower, this should
alleviate the incompatabilities. (We hope!)
Speed:
This version, on a 80486DX-33 PC clone du-jour with 256k cache,
processes data, in either direction, at the rate of approximately
150 bytes per second.
Software:
No special installation is required. We strongly suggest that you
immediately make a backup of your StrangeCryp disk. Use the backup
disk and keep the original disk in a safe place. You may write
protect the use disk, if you wish, to avoid accidental erasure. If
you have a hard disk, copy the StrangeCryp program to it, and use the
program from the hard disk. If you have a computer with only 1 floppy
disk drive and no hard disk, we suggest that you copy the StrangeCryp
program to its own bootable disk, but you may not write protect the
disks if you wish to store any data.
This program contains a facility to enable the keys and setup to be
saved to a file for future use. We most strongly suggest that this
-not- be done for any data of a very sensitive nature, since it would
be possible to decrypt the information by stealing, or otherwise
obtaining, this file. The purpose of this facility is solely to
enable routine communications to be performed using encrypted data.
Routine meaning that you do not care if it is comprimised by theft of
the key file.
We most strongly urge that you develop an algorithm to generate keys,
and that this algorithm never be written or stored in any way except
in your, and the intended recipients, head.
What we mean here, by an algorithm, is a simple to remember set of
rules.
As an example, suppose that you wish to correspond frequently with
Secret Agent Joe., You and Joe then agree on the following:
Key M = 1234567890123
Key O = the month + 3
Key R = the day of the month + 1
Key B = 3.joes telephone number
Key D = . your telphone number
Key X = 11 + sequence of winners at Bay Meadows racetrack
Key Y = 5 + the money take of a certain televangelist
Key Z = 33 + volume of shares on the NY Stock Exchange
Begin = sum of the closing prices of Intel and AMD stocks
Block Size = day of the year + 43
This sort of algorithm is easy to memorize and allows a different
key to be used for each message which is extremely important. Do
not, of course, use exactly this one, since it is now known.
A feature of StrangeCryp is the "begin key", which determines how
many dummy iterations are done before the encryption/decryption will
actually start. We would not recommend that you set this to an
extremely high number for speed reasons. It could be used to enable
the repetitive use of a set of keys, if all the messages were
relatively short and the begin key was greater than the sum of all
the previous messages. We do not really condone this because if one
of the messages encrypted using the same set of keys were to fall
into an opponents hands, it could theoretically comprimise all the
other messages in the set.
When possible the input and output files should be located on a "ram
disk" for maximum speed. This will also ensure security since the
decrypted file will go away when the computer is powered off, and
cannot then be used for an attempted cryptanalysis.
Note that a "warm boot" will not definitely erase the data in memory.
If you have reason to suspect extremely sophisticated opponents, you
should also obtain either a TEMPEST qualified system, or install a
Faraday shielded room in which to work. Either of these will greatly
reduce, or eliminate, the possibility of anyone monitoring you by
means of the electromagnetic radiation given off by most computer
systems.
Remember that the level and degree of security is up to you.
Finally - remember the following for maximum security:
1. Do not permanently record anything, including: the range of
numbers you use, the keys, an encryption sequence that you have used,
any unencrypted text for which a copy of the encrypted text exists, a
copy of your personal method for choosing keys, & etc.
2. Always use a different key to encrypt each data file or message.
If one plaintext is available to an opponent in combination with the
coresponding encrypted material, it may be, at least in theory,
possible to reconstruct the encryption sequence and thereby decrypt
any messages that have been encrypted using the same key set.
Encryption Method:
This program utilizes an implementation of the chaotic random number
generator described by Carroll, Verhagen, and Wong - Cryptologia XVI
#1 Jan. '93
1. The selected blocksize of bytes is converted into a string of
bits (7, or 8, times the length of the block).
2. The first encryption stream moves every bit in the block to some
other position.
3. The second encryption stream is XORed with every bit.
4. The third encryption stream again shuffles the bits.
The third stream comes "free" with the pseudorandom generator, and
is used to incorporate more of the initial key into the encrypted
data.
5. The last input data block is always padded to the selected block
size, and a printable file is also padded to an even line length.
6. The printable output data file comprises columns of hexidecimal
digits, and will be somewhat more than twice the size of the
input file. (This is not required if the file is not
printable.)
Decryption is the inverse of the above. After decryption the output
may have some "garbage" at the bottom caused by padding of the
original file. It is a good idea to end the input file with at least
one carrage return/line feed (enter key).
StrangeCryp was specifically designed to produce printable output
that looks like "secret code". However, if you choose, you may use
the binary output mode, which, while producing a much smaller, albeit
unprintable file, lacks a certain esthetic value.
How to actually use the program:
It is good practice to "compress" the file before encryption using a
program such as LHA or PkZip. This not only reduces the size of the
file, but more importantly from a cryptologic viewpoint, it also
reduces the redundancy inherent in the language and file. After
decryption the end padding will cause no problem and the beginning
padding, if used, may be clipped off before expanding the file.
NOTE: Padding should not be requested for a non-text input file, as
the intitial "garbage" may result in the decrypted file being
unusable until the padding is removed.
NOTE: This program has an input plaintext file size limit of 10,000
bytes.
When you first enter StrangeCryp the opening screen will cover the
program initializing itself. When ready, the message to "press any key
to continue" will appear.
The next screen presents the choices that are available.
You must initialize the program with a set of keys before continuing.
After pressing 1, you will be asked if you wish to enter the keys via
the keyboard, or use an existing file. The first time you use the
program you must enter the keys by hand, unless you choose to use the
included sample keys file.
The "reminder" information that appears is to help you remember what
sort of numbers the keys should be.
(Screen)
M - Large, Odd, Prime(?), O & R - Small Integers, B - Small Real
D - Small Fractional, X - Large >> Y > Z, Begin - Integer,
Block Size - Integer > 16 and < 1001"
Key M =
Key O =
Key R =
Key B =
Key D =
Key X =
Key Y =
Key Z =
Begin =
Block Size =
Large means up to about 15 digits for M, and 14 for X, with Y
being about 100 to 1000 less than X, and Z somewhat less than Y.
A small integer is less than about 100.
A small real is less than about 10, plus up to 12 digits after
the decimal point.
A small fractional is less than 1 but more than about .3 with up
to about 14 digits.
Begin is the number of "dummy" iterations before
encryption/decryption begins. This integer number is only
dependant on the speed of your machine, and your patience.
Block Size is the number of bytes that are encrypted as a block.
The upper limit for this is 1000, and the lower limit is 16.
Remember that a 1000 byte block will result in a block of 8000
bits being shuffled. However, the total time for a file, except
for possible required end padding, is essentially no different
for any block size.
If the question about "printable" is answered in the affirmative,
the output file will be printable using any standard printer. If
answered negatively, the ouput may not be printed, but will be
sigificantly smaller.
Bits 7/8 means whether the input plaintext file is a plain
vanilla 7 bit ASCII file or if there is information contained in
the 8th bit. Any file, plain ASCII or not, may be processed using
the 8 bit mode, but it will be theoretically more secure if the
8th bit is suppressed if it is not needed. The only input files
that may use 7 bit processing are those not containing a
character above ASCII 127. ZIP, or LHA, files require 8 bit
processing.
If the question concerning "padding" is answered in the
affirmative, the input file will be padded with a random number
of random printable characters, both at the beginning and at the
end. This is prior to any padding required for the algorithm, or
file printing formatting. There will, in general, be no problem
in distinguishing the padding from the plain text after
decryption. Do not use padding with a non-text input file, as the
decrypted file may require the padding to be removed before use.
Note: We have observed that on occasion, the operation of the
program is different when the values are entered from the
keyboard versus from a file. It may be required on your
machine(s) to select one method, until testing has proven that
either method is acceptable. However, any key file may be edited
to the desired set of keys.
Note 2: We have recently found that the problem noted in the note
above is caused by some compiler/machine problem that can be
remedied by observing what YOUR saved key file looks like, as
compared to the values that you entered through the keyboard. In
particular, it may prove useful to enter the full allowed 16
digits after the decimal point for key D.
Version, 1.2 fixes some embarassing errors that existed in
version 1.1 & 1.11, and adds 2 new features -
1. Negative Stream Error checking and correction:
The use of certain, but not predeterminable, values for
the encryption keys may result in an encryption stream
value that exhibits negative values. In use these,
rare, values are forced to a positive value, but
intuitively too much forcing is not a good idea. Hence,
the program now incorporates a means for checking for
an excessive number of these values. A percentage of
errors less than about 0.25% should be no cause for
concern.
V 2.1 - It now seems that the negative stream error may
be caused by the lack of a 80x87. It has only ever
shown up once on a machine with an 80x87. (or at least
reported to me)
2. Padding of the plaintext file before encryption:
The repetative use of a standardized header, or ending,
on a message provides a potential tool to assist
cryptanalysis. Padding provides a random length header,
and footer, to the file of random characters. The
penalty for padding is a somewhat larger encrypted
file. If your messages do not always begin, or end, the
same you need not use the padding option. Padding will
usually also occur at the end of the file anyway,
because the files, if they require it, are padded out
to an integer multiple of the selected blocksize and to
yield a full output line.
Version 2.1 fixes still more embarassing errors, adds a larger
encryption block size, establishes a minimum block size, and
incorporates the ability to output a binary/non-printable file. The
code is now specific for 80286, and higher, machines. Any key files
saved by prior versions may still be used if a last line is added to
them - see a new version key file for guidance.
Version 2.2 fixes a major bug(?) by supplying 2 different programs.
The first is called Strng87.Exe, and the other Strngalt.Exe. The
problem was probably the root cause of the other above mentioned
problem - the difference between the funtion and emulation of the
Intel 80x87 math coprocessor, and that of other manufacturers. If all
the machines that will crypt and decrypt messages use Intel chips,
then there should be no problem, and if they all have the
coprocessors then the Strng87.Exe program will be the fastest, and
Strng87.Exe can emulate the Intel chip in software (albeit very
slowly). However, if incompatibilites seem to show up when the
program is run on different machines, then the use of Strngalt.Exe is
suggested. This version utilizes a different math library, and while
it doesn't run quite as quickly as Strng87, it is much quicker than
Strng87 in the emulation mode. The two programs, however, do not
produce files that are compatible with each other. Another approach
is to set an environment variable ( SET NO87=TRUE ) from the dos
prompt, that will tell the Strng87 program to only use the emulation
mode. The files that are produced using the emulation mode seem (so
far) to be compatible with the 80x87 mode using an Intel chip.
Note: V 2.2 was never distributed.
Version 2.5 removes the ability to use the 80x87 ability completely,
as it was causing too much trouble. The new version is only slightly
slower than the version using the coprocessor. The problem was that
this program utilizes the full range of precision of the chip, and
rounding/overflow seemed to be variable among different machines.
Hopefully, the rounding/overflow in the software only version will be
more consistant from machine to machine. It also adds 7/8 bit
processing, and a few other minor changes.
HELP: We are ready to help you with any problems you may have with
this program. For questions you may leave a message on
Genie L.WEINMAN
Compuserve 76530,1142
Internet L.WEINMAN@genie.geis.com
76530.1142@compuserve.com
ATTENTION: A copy of the source code for this program is
available for a $10 copying/mailing fee. Send an
e-mail message for more information.