Internet.Security

TLS supports all of the error alerts defined in SSLv3 with the exception of additional alert codes defined in TLS. The additional error alerts are described in the following:

•decryption failed: A TLS ciphertext is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were incorrect. This message is always fatal.

•record overflow: A TLS record was received with a ciphertext whose length exceeds 214 + 2048 bytes, or the ciphertext decrypted to a TLS compressed record with more

than 214 + 1024 bytes. This message is always fatal.

•unknown ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted CA. This message is always fatal.

•access denied: A valid certificate was received, but when access control was applied, the sender decided not to proceed with the negotiation. This message is always fatal.

•decode error: A message could not be decoded because a field was out of its specified range or the length of the message was incorrect. This message was incorrect. It is always fatal.

•decrypt error: A handshake cryptographic operation failed, including being unable to verify a signature, decrypt a key exchange or validate a finished message.

•export restriction: A negotiation not in compliance with export restrictions was detected; for example, attempting to transfer a 1024-bit ephemeral RSA key for the RSA EXPORT handshake method. This message is always fatal.

•protocol version: The protocol version the client has attempted to negotiate is recognised but not supported due to the fact that old protocol versions might be avoided for security reasons. This message is always fatal.

•insufficient security: Returned instead of hanshake failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client. This message is always fatal.

•internal error: An internal error unrelated to the peer or the correctness of the protocol, such as a memory allocation failure, makes it impossible to continue. This message is always fatal.

•user canceled: This handshake is being cancelled for some reason unrelated to a protocol failure. If the user cancels an operation after the handshake is complete, just closing the connection by sending a close notify is more appropriate. This alert should be followed by a close notify. This message is generally a warning.

•no renegotiation: This is sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these messages would normally lead to renegotiation, but this alert indicates that the sender is not able to renegotiate. This message is always a warning.

For all errors where an alert level is not explicitly specified, the sending party may determine at its discretion whether this is a fatal error or not; if an alert with a level of warning is received, the receiving party may decide at its discretion whether to treat this as a fatal error or not. However, all messages which are transmitted with a level of fatal must be treated as fatal messages.

The authentication, encryption and MAC algorithms are determined by the cipher suite selected by the server and revealed in the server hello message. The compression algorithm is negotiated in the hello messages, and the random values are exchanged in the hello messages.

All that remains is to compute the master secret and the key block. The premaster secret for TLS is calculated in the same way as in SSLv3. The presmater secret should be deleted from memory once the master secret has been computed. As in SSLv3, the master secret in TLS in calculated as a hash function of the premaster secret and two hello random numbers. The TLS master secret computation is different from that of SSLv3 and is defined as follows:

master_secret = PRF(premaster_secret, ‘‘master secret’’, ClientHello.random||ServerHello.random)

The master secret is always exactly 48 bytes (384 bits) in length. The length of the premaster secret will vary depending on key exchange method:

•RSA: When RSA is used for server authentication and key exchange, a 48-byte premaster secret is generated by the client, encrypted with the server’s public key, and sent to the server. The server uses its private key to decrypt the premaster secret. Both parties then convert the premaster secret into the master secret, as specified above.

•Diffie–Hellman: A conventional Diffie – Hellman computation is performed. The negotiated key Z is used as the premaster secret, and is converted into the master secret, as specified above.

The computation of the key block parameters (MAC secret keys, session encryption keys and IVs) is defined as follows:

key_block = PRF(master_secret, ‘‘key expansion’’, SecurityParameters.server_random||

SecurityParameters.client_random)

until enough output has been generated. As with SSLv3, key block is a function of the master secret and the client and server random numbers, but for TLS the actual algorithm is different.

On leaving this chapter, it is recommended that readers search for and find any other small differences between SSL and TLS.

of Standards and Technology (NIST) has published FIPS PUB 186, known as the Digital Signature Standard (DSS). The DSS uses an algorithm that is designed to provide only the digital signature function. Although DSS is a public-key technique, it cannot be used for encryption or key exchange. The DSS approach for generating digital signatures was fully discussed in Chapter 5. The DSS makes use of the secure hash algorithm (SHA-1) described in Chapter 4 and presents a new digital signature algorithm (DSA).

9.1.3 Compression

As a default, PGP compresses the message after applying the signature but before encryption. The placement of Z for compression and Z−1 for decompression is shown in Figures 9.1 and 9.2. This compression algorithm has the benefit of saving space both for e-mail transmission and for file storage. However, PGP’s compression technique will present a difficulty.

Referring to Figure 9.1, message encryption is applied after compression to strengthen cryptographic security. In reality, cryptanalysis will be more difficult because the compressed message has less redundancy than the original message.

Referring to Figure 9.2, signing an uncompressed original message is preferable because the uncompressed message together with the signature are directly used for future verification. On the other hand, for a compressed message, one may consider two cases, either to store a compressed message for later verification or to recompress the message when verification is required. Even if a recompressed message were recovered, PGP’s compression algorithm would present a difficulty due to the fact that different trade-offs in running speed versus compression ratio produce different compressed forms.

PGP makes use of a compression package called ZIP which is functionally equivalent to PKZIP developed by PKWARE, Inc. The zip algorithm is perhaps the most commonly used cross-platform compression technique.

Two main compression schemes, named after Abraham Lempel and Jakob Ziv, were first proposed by them in 1977 and 1978, respectively. These two schemes for text compression (generally referred to as lossless compression) are broadly used because they are easy to implement and also fast.

In 1982 James Storer and Thomas Szymanski presented their scheme, LZSS, based on the work of Lempel and Ziv. In LZSS, the compressor maintains a window of size N bytes and a lookahead buffer. Sliding-window-based schemes can be simplified by numbering the input text characters mod N , in effect creating a circular buffer. Variants of sliding-window schemes can be applied for additional compression to the output of the LZSS compressor, which include a simple variable-length code (LZB), dynamic Huffman coding (LZH) and Shannon – Fano coding (ZIP 1.x). All of them result in a certain degree of improvement over the basic scheme, especially when the data is rather random and the LZSS compressor has little effect.

Recently an algorithm was developed which combines the idea behind LZ77 and LZ78 to produce a hybrid called LZFG. LZFG uses the standard sliding window, but stores the data in a modified tree data structure and produces as output the position of the text in the tree. Since LZFG only inserts complete phrases into the dictionary, it should run faster than other LZ77-based compressors.

Huffman compression is a statistical data compression technique which reduces the average code length used to represent the symbols of an alphabet. Huffman code is an example of a code which is optimal when all symbols probabilities are integral powers of 1/2. A technique related to Huffman coding is Shannon – Fano coding. This coding divides the set of symbols into two equal or almost equal subsets based on the probability of occurrence of characters in each subset. The first subset is assigned a binary 0, the second a binary 1. Huffman encoding always generates optimal codes, but Shannon – Fano sometimes uses a few more bits.

Decompression of LZ77-compressed text is simple and fast. Whenever a (position, length) pair is encountered, one goes to that position in that window and copies length bytes to the output.

9.1.4Radix-64 Conversion

When PGP is used, usually part of the block to be transmitted is encrypted. If only the signature service is used, then the message digest is encrypted (with the sender’s private key). If the confidentiality service is used, the message plus signature (if present) are encrypted (with a one-time symmetric key). Thus, part or all of the resulting block consists of a stream of arbitrary 8-bit octets. However, many electronic mail systems only permit the use of blocks consisting of ASCII text. To accommodate this restriction, PGP provides the service of converting the raw 8-bit binary octets to a stream of printable 7-bit ASCII characters, called radix-64 encoding or ASCII Armor. Therefore, to transport PGP’s raw binary octets through unreliable channels, a printable encoding of these binary octets is needed.

The scheme used for this purpose is radix-64 conversion. Each group of three octets of binary data is mapped into four ASCII characters. This format also appends a CRC to detect transmission errors. This radix-64 conversion is a wrapper around the binary PGP messages, and is used to protect the binary messages during transmission over non-binary channels, such as Internet e-mail.

Table 9.1 shows the mapping of 6-bit input values to characters. The character set consists of the upperand lower-case letters, the digits 0 – 9, and the characters ‘+’ and ‘/’. The ‘=’ character is used as the padding character. The hyphen ‘-’ character is not used.

Thus, a PGP text file resulting from ASCII characters will be immune to the modifications inflicted by mail systems. It is possible to use PGP to convert any arbitrary file to ASCII Armor. When this is done, PGP tries to compress the data before it is converted to Radix-64.

Example 9.1 Consider the mapping of a 24-bit input (a block of three octets) into a four-character output consisting of the 8-bit set in the 32-bit block.

Suppose the 24-bit raw text is:

10110010 01100011 00101001

The hexadecimal representation of this text sequence is b2 63 29.