On Thursday, October 17, 2002, at 05:16 PM, Olaf Kirch via RT wrote:
No. This is regular old CFB, meaning the feedback size is the same as the block size. CFB with 8-bit feedback would take 8 bits of the first 8 bits of the ciphertext and shove out 8 bits of the IV (shifting 8 bits left), then use the result as the IV for generating the second block of keystream. IIRC (and I may not, since no one I've ever seen uses CFB with less than block-sized feedback), Keystream is still generated in block-sized increments using that algorithm.
On Thu, Oct 17, 2002 at 10:24:01PM +0200, Richard Levitte - VMS Whacker wrote:
To make it easier to understand what you're talking about, it would be good to use terms like CFB-8, i.e. where the block size (in bits) is included in the identity.Okay. To make things clearer: I'm working on some code that processes PGP encrypted data. PGP uses CFB in the following fashion:encrypt IV XOR blocksize worth of ciphertext with IV to produce plain text set IV to cipher text encrypt IV ... Not sure if this is called CFB8 - I guess it is but even Schneier isn't totally clear on that, IMHO.
Did you try turning the padding off, as a temporary workaround? I seem to remember that breaking CFB, but I could have been wrong there.
The EVP_CIPHER_CTX_set_padding() macro should be the right way to switch between padded and unpadded CFB. I don't see any reason to have padded CFB other than some standards document mentions it somewhere (I am pretty sure most apps do not use the padding), so I definitely feel padding off should be the default. With OFB, there's no reason for the padding whatsoever, and I don't even see a reason to support it. But, if it does get supported, it should most certainly default to off.I have no problem either if OpenSSL 0.9.7 changes the default behavior of EVP_xxx_cfb() but provides EVP_xxx_cfb8() for those who need it.
John
PGP.sig
Description: PGP signature
