Part 1: General - Computer Security Resource Center - National ...

March, 2007
is the same value as the hash of any given message. Cryptographic message authentication
algorithms (MAC) employ hashes or symmetric encryption algorithms and a key to authenticate
the source of a message, as well as protect its integrity (i.e., detect errors). Digital signatures use
public key algorithms and hash algorithms to provide both authentication and integrity services.
Compared to non-cryptographic integrity or authentication mechanisms, these cryptographic
services are usually computationally more expensive; this seems to be unavoidable, since
cryptographic protections must also resist deliberate attacks by knowledgeable adversaries with
substantial resources.
Cryptographic and non-cryptographic integrity mechanisms may be used together. For example,
consider the TLS protocol (see Part 3). In TLS, a client and a server can authenticate each other,
establish a shared "master key" and transfer encrypted payload data. Every step in the entire TLS
protocol run is protected by strong cryptographic integrity and authentication mechanisms, and
the payload is usually encrypted. Like most cryptographic protocols, TLS will detect any attack
or noise event that alters any part of the protocol run with a given probability. However, TLS has
no error recovery protocol. If an error is detected, the protocol run is simply terminated. Starting
a new TLS protocol run is quite expensive. Therefore, TLS requires a "reliable" transport
service, typically the Internet Transport Control Protocol (TCP), to handle and recover from
ordinary network transmission errors. TLS will detect errors caused by an attack or noise event,
but has no mechanism to recover from them. TCP will generally detect such errors on a packetby-packet
basis and recover from them by retransmission of individual packets, before delivering
the data to TLS. Both TLS and TCP have integrity mechanisms, but a sophisticated attacker
could easily fool the weaker non-cryptographic checksums of TCP. However, because of the
cryptographic integrity mechanism provided in TLS, the attack is thwarted.
There are some interactions between cryptographic and non-cryptographic integrity or errorcorrection
mechanisms that users and protocol designers must take into account. For example,
many encryption modes expand ciphertext errors: a single bit error in the ciphertext can change
an entire block or more of the resulting plaintext. If forward error correction is applied before
encryption, and errors are inserted in the ciphertext during transmission, the error expansion
during the decryption might "overwhelm" the error correction mechanism, making the errors
uncorrectable. Therefore, it is preferable to apply the forward error correction mechanism after
the encryption process. This will allow the correction of errors by the receiving entity’s system
before the ciphertext is decrypted, resulting in “correct” plaintext.
Interactions between cryptographic and non-cryptographic mechanisms can also result in
security vulnerabilities. One classic way this occurs is with protocols that use stream ciphers 32
with non-cryptographic checksums (e.g. CRC-32) and that acknowledge good packets. An
attacker can copy the encrypted packet, selectively modify individual ciphertext bits, selectively
change bits in the CRC, and then send the packet. Using the protocol’s acknowledgement
mechanism, the attacker can determine when the CRC is correct, and therefore, determine certain
bits of the underlying plaintext. At least one widely used wireless encryption protocol has been
broken with such an attack.
32 Stream ciphers encrypt and decrypt one element (e.g., bit or byte) at a time. There are no FIPS algorithms
specifically designated as stream ciphers. However, some of the cryptographic modes defined in [SP 800-38] can
be used with a symmetric block cipher algorithm, such as AES, to perform the function of a stream cipher.
124