This preview shows page 1. Sign up to view the full content.
Unformatted text preview: variant a block size of 8 kilobytes. Assuming that the permutation is fast, this variant is not much slower than basic triple encryption. C = EK3(T(EK2(T(EK1(P))))) T collects a block of input (up to 8 kilobytes in length) and uses a pseudorandomnumber generator to transpose it. A 1bit change in the input causes 8 changed output bytes after the first encryption, up to 64 changed output bytes after the second encryption, and up to 512 changed output bytes after the third encryption. If each block algorithm is in CBC mode, as originally proposed, then the effect of a single changed input bit is likely to be the entire 8 kilobyte block, even in blocks other than the first. Figure 15.2 Triple encryption with padding. The most recent variant of this scheme responded to Biham’s attack on innerCBC by including a whitening pass to hide plaintext patterns. That pass is a stream XOR with a cryptographically secure randomnumber generator called R below. The T on either side of it prevents the cryptanalyst from knowing a priori which key was used to encrypt any given byte on input to the last encryption. The second encryption is labelled nE (encryption with one of n different keys, used cyclically): C = EK3(R(T(nEK2(T(EK1(R)))))) All encryptions are in ECB mode and keys are provided at least for the n + 2 encryption keys and the cryptographically secure randomnumber generator. This scheme was proposed with DES, but works with any block algorithm. I know of no analysis of the security of this scheme. 15.3 Doubling the Block Length
There is some argument in the academic community whether a 64bit block is long enough. On the one hand, a 64bit block length only diffuses plaintext over 8 bytes of ciphertext. On the other hand, a longer block length makes it harder to hide patterns securely; there is more room to make mistakes. Some propose doubling the block length of an algorithm using multiple encryptions [299]. Before implementing any of these, look for the possibility of meetinthemiddle attacks. Richard Outerbridge’s scheme [300], illustrated in Figure 15.3, is no more secure than singl...
View
Full
Document
This note was uploaded on 10/18/2010 for the course MATH CS 301 taught by Professor Aliulger during the Fall '10 term at Koç University.
 Fall '10
 ALIULGER
 Cryptography

Click to edit the document details