Cryptographic Protocols - Everyday Cryptography - page 304

because the same key K might later be used for encryption, thus abusing the
principle of key separation (see Section 10.6.1).
The case for . In Section 6.3.1 we outlined a number of problems that may arise
if encryption is used to provide data origin authentication. These mainly arose
when the plaintext was long and unformatted. However, in this case the reply
text is short and has a specific format. Thus, if a block cipher such as AES is
used then it is possible that the reply text is less than one block long, hence no
'block manipulation' will be possible. Even if the reply text is two blocks long
and ECB mode is used to encrypt these two blocks, the format of the reply text
is specific and any manipulation is likely to be noticed by Bob (assuming of
course that he checks for it).
It is safest to argue that Protocol 4 does not meet the three security goals, since
the 'case for' requires some caveats concerning the type of encryption mechanism
used. For example, it is not likely to meet the goals if we implement E using a
stream cipher.
There are cryptographic protocols in standards that do use encryption to
deduce data origin authentication in the style of Protocol 4. Such standards
normally include advice on what type of encryption mechanism it is 'safe' to
use. Good advice in this case would be to use a block cipher in an authenticated-
encryption mode of operation, as discussed in Section 6.3.6. We will see such an
example in Section 9.4.3. However, encryption tends only to be used in this way
if confidentiality of the message data is also required. In Protocol 4 this is not the
case, so it would be much better to use Protocol 1.
9.3.6 Protocol 5
Protocol 5, depicted in Figure 9.7, is very similar to Protocol 1, except that the
nonce generated by Bob is replaced by a timestamp generated by Bob.
PROTOCOL ASSUMPTIONS
These are the same as the assumptions for Protocol 1, except that the need for
Bob to have a source of randomness is replaced by:
Bob can generate and verify integrity-protected timestamps . This requires Bob
to have a system clock. Requiring T B to be integrity-protected means that it
cannot be manipulated by an attacker without subsequent detection of this by
Bob. We discussed mechanisms for doing this in Section 8.2.1.
PROTOCOL DESCRIPTION
The description of Protocol 5 is exactly as for Protocol 1, except that:
• Instead of generating a nonce r B , Bob generates an integrity-protected
timestamp T B . This is then included in both the request (by Bob) and the reply
(by Alice).
• As part of his checks on the reply, Bob checks that the reply text includes T B .