On Thursday, October 17, 2002, at 04:22 PM, Richard Levitte - VMS Whacker wrote:
Those modes *require* that a multiple of {block_size} bytes get
through to get properly encrypted/decrypted.
In case I wasn't clear last time (rereading, I'm afraid I wasn't), the
above quoted text is wrong.CFB (in block-aligned sizes) does require a full block's worth of ciphertext to generate the keystream for the NEXT block of ciphertext. However, if you've got a partial block of plaintext, you just XOR that partial block with the appropriate bytes from the one keystream block you've already generated. You don't have to wait for more plaintext to come in. And, if that plaintext turns out to be the last of it, there's absolutely no reason to pad, because each bit of the output corresponds directly with a bit of the input (thus blocks are ALWAYS one bit if you want to think of it in terms of blocks).
OFB should never have a feedback size other than the block size. Essentially, OFB generates a keystream by encrypting the IV, then continually encrypting the previous block generated. With OFB, you can precompute your keystream before you have data to encrypt (just as you can with RC4). When data comes in, you simply XOR it with the keystream, meaning that once again, if there's a notion of blocks, they'd have to be one-bit blocks.
Hope I've communicated my message in some combination of these two attempts :)
John
PGP.sig
Description: PGP signature
