Cryptography Reference
In-Depth Information
Probably the most accurate answer to this question is that
it might be, but it is
certainly not always valid
. Here are three situations that illustrate this:
ECB mode
. Suppose that Alice and Bob use ECB mode (see Section 4.6.1) to
encrypt their message (which is perhaps not the wisest choice). An attacker
who intercepts the ciphertext on its way to Bob cannot determine the plaintext
because he does not know key
K
. However, the attacker could rearrange
the ciphertext blocks into a different order, or delete one or more of the
ciphertext blocks. If the message is a sentence in English then there is a good
chance that Bob might notice something odd when he decrypts the modified
ciphertext block sequence, although there is certainly a chance that he might
not. However, if the ciphertext consists of a sequence of database entries, one
for each block, it may not be so easy to detect.
Stream cipher
. Suppose that Alice uses a stream cipher to encrypt her message
to Bob. An attacker knows that changing one bit of the ciphertext, which
is often referred to as
bit flipping
, will change the corresponding bit of the
plaintext. Although the attacker will not normally know the exact impact of
making this change to the plaintext, there are many applications where the
attacker may have a reasonable idea of what the impact is likely to be. For
example, if the attacker knows that the first part of the message is a date
then flipping the ciphertext bit has a reasonable chance of changing this to an
alternative date.
Randomly generated plaintext
. Suppose that Alice wishes to send a plaintext to
Bob that appears to him to be 'randomly' generated in the sense that it is not in
any natural language and does not contain any obvious structure. This is not
such a strange proposition since, as we will learn in Section 10.4, a common
technique for distributing symmetric keys is to encrypt them using another
(higher level) symmetric key. The attacker is now in a very strong position
because they can modify Alice's ciphertext block in any way they like and
probably succeed in fooling Bob. This is because the plaintext looks 'randomly'
generated and so Bob cannot tell the difference between a valid plaintext and
a modified one. Even worse, if the attacker knows that Bob is expecting such a
message, the attacker can send a false block to Bob (before Alice sends any data
to Bob). When Bob decrypts this block he may think that it was the message
fromAlice and will decrypt it. Of course the attacker does not gain significantly
because even the attacker does not know what the plaintext is that corresponds
to the modified (or false) ciphertext block. However, in both of these cases
data origin authentication has not been provided since Bob has been fooled
into believing that some data came from Alice, when it actually came from the
attacker.
It should thus be clear that, as a rule,
encryption does not provide data
origin authentication
. It is thus good practice to use separate cryptographic
mechanisms if both confidentiality and data origin authentication are required
(see Section 6.3.6).
