- block ciphers encrypt a fixed size block of information
- eg. DES encrypts 64-bit blocks of data, using a 56-bit key
- need some way of specifying how to use it in practise, given that we usually have an arbitrary amount of information to encrypt
- way a block cipher is used is called its Mode of Use
- four have been defined for DES in ANSI standard ANSI X3.106-1983 Modes of Use
- modes are either:
- Block Modes
- processes message in blocks (ECB, CBC)
- Stream Modes
- processes message as a bit/byte stream (CFB, OFB)
DES (or any block cipher) forms a basic building block, which en/decrypts a fixed sized block of data. However to use these in practise, we usually need to handle arbitrary amounts of data, which may be available in advance (in which case a block mode is appropriate), and may only be available a bit/byte at a time (in which case a tream mode is used).
- message is broken into independent blocks which are encrypted
- each block is a value which is substituted, like a codebook, hence name
- each block is independent of all others
Ci = DESK1 (Pi)
Stallings Fig 3.11 ECB is the simplest of the modes, used when only a single block of info needs to be sent (eg. a session key encrypted using a master key)
- repetitions in message can be reflected in ciphertext
- if aligned with message block
- particularly with data such graphics
- or with messages that change very little, which become a code-book analysis problem
- weakness due to encrypted message blocks being independent
- hence only really useful when sending a few blocks of data
ECB is not appropriate for any quantity of data, since repetitions can be seen, esp. with graphics, and because the blocks can be shuffled/inserted without affecting the encryption.
- message is broken into blocks
- but these are linked together in the encryption operation
- ie cipher blocks are chained with plaintext, hence name
- use a known Initial Vector (IV) to start process
Ci = DESK1(Pi XOR Ci-1) C-1 = IV
Stallings Fig 3.12 To overcome the problems of repetitions and order independence in ECB, want some way of making the ciphertext dependent on all blocks before it. This is what CBC gives us, by combining the previous ciphertext block with the current message block before encrypting. To start the process, use an Initial Value (IV), which is usually wellknown (often all 0's), or otherwise is sent, ECB encrypted, just before starting CBC use. CBC mode is applicable whenever large amounts of data need to be sent securely, provided that its available in advance (eg email, FTP, web etc)
- each ciphertext block is dependent on all message blocks before it
- most common mode of use when data available in advance
- thus a change in the message affects the ciphertext block after the change as well as the original block
- to start need an Initial Value (IV) which must be known by both
sender and receiver
- however if IV is sent in the clear, an attacker can change bits of the first block, and change IV to compensate
- hence either IV must be a fixed value (as in EFTPOS) or it must be sent encrypted in ECB mode before rest of message
- also at the end of the message, have to handle a possible last short block
- either pad last block (usually with count of pad size)
- eg. [ b1 b2 b3 0 0 0 0 5] <- 3 data bytes, then 5 bytes pad+count
- or use some fiddling to double up last two blocks
- see Davies section 4.2 for examples
One issue is how to handle the last block, which may well not be complete. In general have to pad this block (typically with 0's), and then must recognise padding at other end - may be obvious (eg in text the 0 value should usually not occur), or otherwise must explicitly have the last byte as a count of how much padding was used (including the count). Note that if this is done, if the last block IS an even multiple of 8 bytes, will have to add an extra block, all padding so as to have a count in the last byte.
- the message is treated as a stream of bits
- which are added to the output of the block cipher
- result is feed back for next stage (hence name)
- standard allows any number of bit (1,8 or 64 or whatever) to be feed back
- denoted CFB-1, CFB-8, CFB-64 etc
- in practice it is most efficient to consume all 64 bits
- call this CFB-64
Ci = Pi XOR DESK1 (Ci-1) C-1 = IV
Stallings Fig 3.13 If the data is only available a bit/byte at a time (eg. terminal session, sensor value etc), then must use some other approach to encrypting it, so as not to delay the info. Idea here is to use the block cipher essentially as a pseudo-random number generator (see stream cipher lecture later) and to combine these "random" bits with the message. Note as mentioned before, XOR is an easily inverted operator (just XOR with same thing again to undo). Again start with an IV to get things going, then use the ciphertext as the next input. As originally defined, idea was to "consume" as much of the "random" output as needed for each message unit (bit/byte) before "bumping" bits out of the buffer and re-encrypting. This is wasteful though, and slows the encrpytion down as more encrpytions are needed. An alternate way to think of it is to generate a block of "random" bits, consume them as message bits/bytes arrive, and when they're used up, only then feed a full block of ciphertext back. This is CFB-64 mode, the most efficient. This is the usual choice for quantities of stream oriented data, and for authentication use.
- appropriate when data inherently arrives in bits/bytes
- most common stream mode
- limitation is need to stall while do block encryption after every 64 bits
- block cipher is use in encryption mode at both ends
- errors propogate for several blocks after the error
CFB is the usual stream mode. As long as can keep up with the input, doing encryptions every 8 bytes. A possible problem is that if its used over a "noisy" link, then any corrupted bit will distroy values in the current and next blocks (since the current block feeds as input to create the random bits for the next). So either must use over a reliable network transport layer (pretty usual) or use OFB.
- the message is treated as a stream of bits
- output of block cipher is added to the message
- and output if then feed back (hence name)
- thus feedback is independent of the message
- can be computed in advance
Ci = Pi XOR Oi Oi = DESK1(Oi-1) O-1 = IV
Stallings Fig 3.14 The alternative to CFB is OFB. Here the generation of the "random" bits is independent of the message being encrypted. The advantage is that firslty, they can be computed in advance, good fro bursty traffic, and secondly, any bit error only affects a single bit. Thus this is good for noisy links (eg satellite TV transmissions etc)
- used where the error feedback is a problem
- or where the encryptions must be done before the message is available
- superficially similar to CFB
- but the feedback is from the output of the block cipher and is independent of the message
- a variation of a Vernam cipher
- hence must never reuse the same sequence (key+IV)
- sender and receiver must remain in sync, and some recovery method is needed to ensure this occurs
- although originally specified with m-bit feedback in the standards
- subsequent research has shown that only 64-bit OFB should ever be used
- and this is the most efficient use anyway
Because the "random" bits are independent of the message, they must never ever be used more than once (otherwise the 2 ciphertexts canbe combined, cancelling these bits, and leaving a "book" cipher to solve). Also, as noted, should only ever use afull block feedback ie OFB-64 mode.