Security Engineering. Ross Anderson
Читать онлайн книгу.
a keystream to plaintext can protect confidentiality, but it can't detect modification of the file. For that, we might make a hash of the file and keep that somewhere safe. It may be easier to protect the hash from modification than the whole file.
One-time pad systems are a close fit for our theoretical model, except in that they are used to secure communications across space rather than time: the two communicating parties have shared a copy of a keystream in advance. Vernam's original telegraph cipher machine used punched paper tape; Marks describes how SOE agents’ silken keys were manufactured in Oxford by retired ladies shuffling counters; we'll discuss modern hardware random number generators in the chapter on Physical Security.
A real problem with keystream generators is to prevent the same keystream being used more than once, whether to encrypt more than one backup tape or to encrypt more than one message sent on a communications channel. During World War II, the amount of Russian diplomatic traffic exceeded the quantity of one-time tape they had distributed in advance to their embassies, so it was reused. But if
To avoid this, the normal engineering practice is to have not just a key but also a seed (also known as an initialisation vector or IV) so we start the keystream at a different place each time. The seed
5.3.3 Random permutations – block ciphers
The third type of primitive, and the most important in modern cryptography, is the block cipher, which we model as a random permutation. Here, the function is invertible, and the input plaintext and the output ciphertext are of a fixed size. With Playfair, both input and output are two characters; with DES, they're both bit strings of 64 bits. Whatever the number of symbols and the underlying alphabet, encryption acts on a block of fixed length. (So if you want to encrypt a shorter input, you have to pad it as with the final ‘z’ in our Playfair example.)
We can visualise block encryption as follows. As before, we have an elf in a box with dice and a scroll. This has on the left a column of plaintexts and on the right a column of ciphertexts. When we ask the elf to encrypt a message, it checks in the left-hand column to see if it has a record of it. If not, it rolls the dice to generate a random ciphertext of the appropriate size (and which doesn't appear yet in the right-hand column of the scroll), and then writes down the plaintext/ciphertext pair in the scroll. If it does find a record, it gives us the corresponding ciphertext from the right-hand column.
When asked to decrypt, the elf does the same, but with the function of the columns reversed: he takes the input ciphertext, looks for it on the right-hand scroll, and if he finds it he gives the message with which it was previously associated. If not, he generates a new message at random, notes it down and gives it to us.
A block cipher is a keyed family of pseudorandom permutations. For each key, we have a single permutation that's independent of all the others. We can think of each key as corresponding to a different scroll. The intuitive idea is that a cipher machine should output the ciphertext given the plaintext and the key, and output the plaintext given the ciphertext and the key, but given only the plaintext and the ciphertext it should output nothing. Furthermore, nobody should be able to infer any information about plaintexts or ciphertexts that it has not yet produced.
We will write a block cipher using the notation established for encryption in the chapter on protocols:
The random permutation model also allows us to define different types of attack on block ciphers. In a known plaintext attack, the opponent is just given a number of randomly chosen inputs and outputs from the oracle corresponding to a target key. In a chosen plaintext attack, the opponent is allowed to put a certain number of plaintext queries and get the corresponding ciphertexts. In a chosen ciphertext attack he gets to make a number of ciphertext queries. In a chosen plaintext/ciphertext attack he is allowed to make queries of either type. Finally, in a related key attack he can make queries that will be answered using keys related to the target key
In each case, the objective of the attacker may be either to deduce the answer to a query he hasn't already made (a forgery attack), or to recover the key (unsurprisingly known as a key recovery attack).
This precision about attacks is important. When someone discovers a vulnerability in a cryptographic primitive, it may or may not be relevant to your application. Often it won't be, but will have been hyped by the media – so you will need to be able to explain clearly to your boss and your customers why it's not a problem. So you have to look carefully to find out exactly what kind of attack has been found, and what the parameters are. For example, the first major attack announced on the Data Encryption Standard algorithm (differential cryptanalysis) required
Which sort of attacks you should be worried about depends on your application. With a broadcast entertainment system, for example, a hacker can buy a decoder, watch a lot of movies and compare them with the enciphered broadcast signal; so a known-plaintext attack might be the main threat. But there are surprisingly many applications where chosen-plaintext attacks are possible. A historic example is from World War II, where US analysts learned of Japanese intentions for an island ‘AF’ which they suspected meant Midway. So they arranged for Midway's commander to send an unencrypted message reporting problems with its fresh water condenser, and then intercepted a Japanese report that ‘AF is short of water’. Knowing that Midway was the Japanese objective, Admiral Chester Nimitz was waiting for them and sank four Japanese carriers, turning the tide of the war [1003].
The other attacks are more specialised. Chosen plaintext/ciphertext attacks may be a worry where the threat is a lunchtime attack: someone who gets temporary access to a cryptographic device while its