paper2

Best algorithm for LZW ..C language

some lazy and crazy enough to use easily-guessable passwords, four-letter
words, or whatever.
Hashing techniques make it almost as quick to check a candidate against a
group of encrypted passwords as against a single one.
.pp
A technique called ``salting'' protects against this kind of attack.
Whenever a user's password is initialized or changed, a small random number
called the ``salt'' is generated (perhaps from the time of day).
Not only is this combined with the password when it is encrypted, but as
Figure\ 1 shows it is also stored in the password file for everyone to see.
Every time someone claiming to be that user logs in, the salt is combined with
the password offered before being encrypted and compared
with whatever is stored in the password file.
For example, say my password was ``w#xs27'' (it isn't!).
If the salt is ``U6'' (as in Figure\ 1), the system will apply its one-way
function to ``w#xs27U6'' to get the encrypted password.
.pp
Since all can see the salt, it is no harder for anyone to guess
an individual user's password.
One can salt guesses just as the system does.
But it \fIis\fR harder to search a group of passwords, since the salt will be
different for each, rendering it meaningless to compare a single encrypted
password against all those in the group.
Suppose you were checking to see if anyone had the password ``hello''.
Without salting, you simply apply the one-way function to this word and
compare the result with everyone's encrypted password.
But with salting it's not so easy, since to see if my password is ``hello''
you must encrypt ``helloU6'', and the salt is different for everyone.
.rh "Forced-choice passwords."
The trouble with letting users choose their own passwords is that they often
make silly, easily-guessed, choices.
Many systems attempt to force people to choose more ``random'' passwords, and
force them to change their password regularly.
All these attempts seem to be complete failures.
The fundamental problem is that people have to be able to remember their
passwords, because security is immediately compromised if they are written
down.
.pp
There are many amusing anecdotes about how people thwart systems that attempt
to dictate when they have to change their passwords.
I had been using a new system for some weeks when it insisted that I change my
password.
Resenting it ordering me about, I gave my old password as the new one.
But it was programmed to detect this ruse and promptly told me so.
I complained to the user sitting beside me.
``I know,'' she said sympathetically.
``What I always do is change it to something else and then immediately
change it back again!''  \c
Another system remembered your last several passwords, and insisted on a
once-a-month change.
So people began to use the name of the current month as their password!
.rh "Wiretaps."
Obviously any kind of password protection can be thwarted by a physical
wiretap.
All one has to do is watch as you log in and make a note of your password.
The only defense is encryption at the terminal.
Even then you have to be careful to ensure that someone can't intercept
your encrypted password and pose as you later on by sending this
\fIencrypted\fR string to the computer \(em after all, this is what the
computer sees when you log in legitimately!
To counter this, the encryption can be made time-dependent so that the same
password translates to different strings at different times.
.pp
Assuming that you, like 99.9% of the rest of us, don't go to the trouble of
terminal encryption, when was the last time you checked the line between your
office terminal and the computer for a physical wiretap?
.rh "Search paths."
We will see shortly that you place yourself completely at the mercy of other
users whenever you execute their programs, and they
can do some really nasty things like spreading infection to your files.
However, you don't necessarily have to execute someone else's program overtly,
for many systems make it easy to use other people's
programs without even realizing it.
This is usually a great advantage, for you can install programs so that you
or others can invoke them just like ordinary system programs, thereby
creating personalized environments.
.pp
Figure\ 4 shows part of the file hierarchy in our system.
The whole hierarchy is immense \(em I alone have something like 1650 files,
organized into 200 of my own directories under the ``ian'' node shown in the
Figure, and there are hundreds of other users \(em and what is shown is just a
very small fragment.
Users can set up a ``search path'' which tells the system
where to look for programs they invoke.
For example, my search path includes the 6 places that are circled.
Whenever I ask for a program to be executed, the system seeks it in these
places.
It also searches the ``current directory'' \(em the one where I happen to be
at the time.
.pp
To make it more convenient for you to set up a good working environment, it
is easy to put someone else's file directories on your search path.
But then they can do arbitrary damage to you, sometimes completely
accidentally.
For example, I once installed a spreadsheet calculator called ``sc'' in one
of my directories.
Unknown to me, another user suddenly found that the Simula compiler stopped
working and entered a curious mode where it cleared his VDT screen and wrote
a few incomprehensible characters on it.
There was quite a hiatus.
The person who maintained the Simula compiler was away,
but people could see no reason for the compiler to have been altered.
Of course, told like this it is obvious that the user had my directory on his
search path and I had created a name conflict with \fIsc\fR, the Simula
compiler.
But it was not obvious to the user, who rarely thought about the search path
mechanism.
And I never use the Simula compiler and had created the conflict in all
innocence.
Moreover, I didn't even know that other users had my directory on their search
paths!
This situation caused only frustration before the problem was diagnosed and
fixed.
But what if I were a bad guy who had created the new \fIsc\fR program to
harbor a nasty bug (say one which deleted the hapless user's files)?
.pp
You don't necessarily have to put someone on your search path to run the
risk of executing their programs accidentally.
As noted above, the system (usually) checks your current working directory
for the program first.
Whenever you change your current workplace to another's directory, you
might without realizing it begin to execute programs that had been
planted there.
.pp
Suppose a hacker plants a program with the same name as a common
utility program.
How would you find out?
The \s-2UNIX\s+2 \fIls\fR command lists all the files in a directory.
Perhaps you could find imposters using \fIls\fR?  \(em Sorry.
The hacker might have planted another program, called \fIls\fR, which
simulated the real \fIls\fR exactly except that it lied about its own
existence and that of the planted command!
The \fIwhich\fR command tells you which version of a program you
are using \(em whether it comes from the current directory, another user's
directory, or a system directory.
Surely this would tell you?  \(em Sorry.
The hacker might have written another \fIwhich\fR which lied about itself,
about \fIls\fR, and about the plant.
.pp
If you put someone else on your search path, or change into their directory,
you're implicitly trusting them.
You are completely at a user's mercy when you execute one of their programs,
whether accidentally or on purpose.
.rh "Programmable terminals."
Things are even worse if you use a ``programmable'' terminal.
Then, the computer can send a special sequence of characters to command the
terminal to transmit a particular message whenever a particular key is struck.
For example, on the terminal I am using to type this article, you could
program the \s-2RETURN\s+2 key to transmit the message ``hello'' whenever it
is pressed.
All you need to do to accomplish this is to send my terminal the character
sequence
.LB
\s-2ESCAPE\s+2 P ` + { H E L L O } \s-2ESCAPE\s+2
.LE
(\s-2ESCAPE\s+2 stands for the \s-2ASCII\s+2 escape character, decimal 27,
which is invoked by a key labeled ``Esc''.)  \c
This is a mysterious and ugly incantation, and I won't waste time
explaining the syntax.
But it has an extraordinary effect.
Henceforth every time I hit the return key, my terminal will transmit the
string ``hello'' instead of the normal \s-2RETURN\s+2 code.
And when it receives this string, the computer I am connected to will try to
execute a program called ``hello''!
.pp
This is a terrible source of insecurity.
Someone could program my terminal so that it executed one of \fItheir\fR
programs whenever I pressed \s-2RETURN\s+2.
That program could reinstate the \s-2RETURN\s+2 code to make it
appear afterwards as though nothing had happened.
Before doing that, however, it could (for example) delete all my files.
.pp
The terminal can be reprogrammed just by sending it an ordinary character
string.
The string could be embedded in a file, so that the terminal would be bugged
whenever I viewed the file.
It might be in a seemingly innocuous message;
simply reading mail could get me in trouble!
It could even be part of a file \fIname\fR, so that the bug would appear
whenever I listed a certain directory \(em not making it my current directory,
as was discussed above, but just \fIinspecting\fR it.
But I shouldn't say ``appear'', for that's exactly what it might not do.
I may never know that anything untoward had occurred.
.pp
How can you be safe?
The programming sequences for my terminal all start with \s-2ESCAPE\s+2,
which is an \s-2ASCII\s+2 control character.
Anyone using such a terminal should whenever possible work through a
program that exposes control characters.
By this I mean a program that monitors output from the computer and translates
the escape code to something like the 5-character sequence ``<ESC>''.
Then a raw \s-2ESCAPE\s+2 itself never gets sent to the terminal,
so the reprogramming mechanism is never activated.
.pp
Not only should you avoid executing programs written by people you don't
trust, but in extreme cases you should take the utmost care in \fIany\fR
interaction with untrustworthy people \(em even reading their electronic
mail.
.sh "Trojan horses: getting under the skin"
.pp
The famous legend tells of a huge, hollow wooden horse filled with Greek
soldiers which was left, ostensibly as a gift, at the gates of the city of
Troy.
When it was brought inside, the soldiers came out at night and
opened the gates to the Greek army, which destroyed the city.
To this day, something used to subvert an organization from within by abusing
misplaced trust is called a Trojan horse.
.pp
In any computer system for which security is a concern, there must be things
that need protecting.
These invariably constitute some kind of information (since the computer is,
at heart, an information processor), and such information invariably outlasts
a single login session and is therefore stored in the computer's file system.
Consequently the file system is the bastion to be kept secure, and will be
the ultimate target of any invader.
Some files contain secret information that not just anyone may read,
others are vital to the operation of an organization and must at all costs
be preserved from surreptitious modification or deletion.
A rather different thing that must be protected is the ``identity'' of each
user.
False identity could be exploited by impersonating someone else in order to
send mail.
Ultimately, of course, this is the same as changing data in mailbox files.
Conversely, since for each and every secret file \fIsomeone\fR must
have permission to read and alter it, preserving file system security
requires that identities be kept intact.
.rh "What might a Trojan horse do?"
The simplest kind of Trojan horse turns a common program like a text editor
into a security threat by implanting code in it which secretly reads
or alters files it is not intended to.
An editor normally has access to all the user's
files (otherwise they couldn't be altered).
In other words, the program runs with the user's own privileges.
A Trojan horse in it can do anything the user himself could do, including
reading, writing, or deleting files.
.pp
It is easy to communicate stolen information back to the person who bugged
the editor.
Most blatantly, the access permission of a secret file could be changed so
that anyone can read it.
Alternatively the file could be copied temporarily to disk \(em most systems
allocate scratch disk space for programs that need to create temporary working
files \(em and given open access.
Another program could continually check for it and, when
it appeared, read and immediately delete it to destroy the trace.
More subtle ways of communicating small amounts of information might be to
rearrange disk blocks physically so that their addresses formed a code, or to
signal with the run/idle status of the process to anyone who monitored the
system's job queue.
Clearly, any method of communication will be detectable by others \(em in
theory.
But so many things go on in a computer system that messages can easily be
embedded in the humdrum noise of countless daily events.
.pp
Trojan horses don't necessarily do bad things.
Some are harmless but annoying, created to meet a challenge rather than to
steal secrets.
One such bug, the ``cookie monster'', signals its presence by announcing
to the unfortunate user ``I want a cookie''.
Merely typing the word ``cookie'' will satiate the monster and cause it to
disappear as though nothing had happened.
But if the user ignores the request, although the monster appears to go
away it returns some minutes later with ``I'm hungry; I really want a
cookie''.