Cryptography Reference
In-Depth Information
attacker to produce a valid MAC on a message M that consists of M with some
additional data appended to it. This is an example of MAC forgery, since the
attacker has been able to compute a valid MAC on M without knowing the key.
Step 2 is thus necessary if we are to make a secure MAC from a hash function.
6.3.5 MACs and non-repudiation
Recall from Section 1.3.1 that non-repudiation is the assurance that an entity
cannot deny any previous commitments or actions. Themost important limitation
of MACs is that they do not provide a non-repudiation service. To see this,
consider what happens if the sender and receiver get involved in a dispute over
whether a particularMACwas attached to a particularmessage. DoMACs provide
a proof that a message was sent by the sender to the receiver?
The answer, at least in most cases, is no. Nobody can compute a MAC other
than the sender and the receiver. This means that a MAC on a message is evidence
that either the sender or the receiver computed it. This provides protection from
any third-party claims to have computed it, but it does not protect the sender
and receiver from one another. The sender could deny having sent the MAC and
claim that the receiver forged it, or vice versa. Since it is impossible to determine
which of the two parties computed the MAC, it is thus impossible to provide
non-repudiation.
This 'limitation' of MACs arises because they are based on symmetric
cryptography and thus require trust between the sender and receiver for their
use. If non-repudiation is required then we normally need to look at techniques
based on public-key cryptography. That said, there are situations where a MAC
can be used to provide a non-repudiation service. We will discuss these situations
in Section 7.2.
6.3.6 Using MACs with encryption
In our analysis of MACs we have assumed that we only wish to provide data origin
authentication for a message. Thus our assumption was that the message was sent
in the clear to the receiver. However, there are many applications where this is
not a reasonable assumption.
The majority of cryptographic applications that require confidentiality also
tend to require data origin authentication. Indeed, some people argue that
true confidentiality can never be provided by the use of encryption on its
own and hence confidentiality always needs to be accompanied by data origin
authentication.
A practical issue that often arises in applications that require both of these
security services is that there may be some message data that must not be
encrypted, but should be authenticated. Examples of this might be a packet header
that contains routing information, or a header that contains a key identifier that
 
Search WWH ::




Custom Search