On Thursday, October 17, 2002, at 05:16 PM, Olaf Kirch via RT wrote:
> > 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. 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. 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. > > 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. 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. John ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
