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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
