When we are considering the quality of an encryption system, we assume
the person trying to decode the message knows what the general procedure
is and is looking at the ciphertext-- the only thing he does not have
is the key. We also assume the person sending messages does not spend
time trying to contrive a difficult-to-read message by using unusual
words or letter frequencies-- the sender is counting on the system to
provide all the needed security.
Usually one assumes the person trying to break the code is only
working with the ciphertext. However, there are situations in which
both plaintext and ciphertext of a previously encoded message are
available. For example, I often keep encrypted versions of examinations
on a mainframe computer, only decoding them just before having them
printed, and deleting the plaintext file immediately afterward. If a
student was able to look at my files, he could keep a copy of the
encoded test and compare this with the test he took. As we will see,
this may be very useful in decoding future tests.
[One countermeasure against this type of known-plaintext attack
is to continually change keys, assuming an encryption using one key is
not helpful on a different key. It can become difficult to keep track
of the different keys in use, especially if they are long.]
A more demanding standard is that a code may be safe against a
chosen-plaintext attack. We are imagining that the encryption is
done by a machine, and that unauthorized persons may have access to
the machine (although we assume they are only using it in the normal
way, not allowed to take it apart).