On Thursday, October 17, 2002, at 04:22 PM, Richard Levitte - VMS Whacker wrote:
In message <[EMAIL PROTECTED]> on Thu, 17 Oct 2002 14:15:22 -0400, John Viega <[EMAIL PROTECTED]> said:The feedback size is important when calculating the keystream, but encryption in these modes simply happens by XORing with a keystream. It's okay to have more keystream generated than you have plaintext... there's never any reason to block-align
I'm honestly unsure what you guys are talking about. Could it
confusion over the fact that we have only implemented CFB-xx and
OFB-xx, where xx is the block size of the underlying algorithm? This
means that for all algorithms other than AES, we have implemented
CFB-64 and OFB-64, and for AES we have implemented CFB-128 and
OFB-128.
Note that the actual encryption part is just XOR, and therefore has no real notion of blocks. CFB, CTR and OFB modes are simply KEYSTREAM GENERATORS in the way that RC4 is a keystream generator. They just happen to be a generic way of turning a block cipher into a pseudo-random number generator.
Perhaps it would help to show you how things work differently in 0.9.6 and 0.9.7. Try this code out in each one:
#include <openssl/evp.h>
int main(int argc, char **argv) {
EVP_CIPHER_CTX c;
char key[128] = {0,};
char iv[128] = {0,};
char in[256]={0,};
char out[256];
int olen,i, o2;
#define CIPHER() EVP_bf_cfb()
#define HOWMANY 148
EVP_EncryptInit(&c, CIPHER(), (char *)key, iv);
EVP_EncryptUpdate(&c, out, &olen, in, HOWMANY);
EVP_EncryptFinal(&c, out+olen,&o2);
olen += o2;
printf("Olen = %d\n", olen);
for(i=0;i<olen;i++) {
printf("%02x ", (unsigned char)out[i]);
}
printf("\n");
}
This returns 148 in 0.9.6, and it returns 152 in 0.9.7 (b3 at least). The same thing happens in OFB mode. What's going on is that PKCS padding is getting added when it never was previously.
The new behavior is technically right for CFB mode with block-sized feedback. However, with block sized-feedback, it's particularly easy to totally skip the shift register, and just generate a block of keystream at a time by holding on to the previous block of ciphertext as it becomes available.
The new behavior is quite wrong for OFB mode. OFB mode should NOT pad by default (go to the NIST modes document and you'll see ECB, CBC and CFB listed as the modes that should have padding; OFB and CTR should not).
John
Those modes *require* that a multiple of {block_size} bytes get
through to get properly encrypted/decrypted.
I'm thinking of implementing CFB-8 as well. That would give the
streaming properties that you seem to desire.
viega> Hmm, I just noticed this problem yesterday, as well. As a temporary
viega> work-around, you can turn off padding with OFB mode, and everything
viega> works as expected. I'm pretty sure I got an error related to block
viega> alignment when I turned off padding in CFB mode.
viega>
viega> However, the CFB mode behavior is now technically CORRECT whereas it
viega> never was in previous versions, at least according to things like the
viega> NIST specification of the mode, because the shift register is always
viega> supposed to fill up before doing an encryption (Appendix A of the new
viega> modes document explicitly states that CFB needs to be padded,
viega> reinforcing this interpretation). Yes, there are protocols that rely
viega> on the streaming version of CFB, though. OpenSSL should clearly
viega> support both, but it's not as clear to me what the default should be
viega> for CFB. For OFB, the default is clear (and the current state of
viega> affairs is clearly wrong :).
viega>
viega> John
viega>
viega> On Thu, Oct 17, 2002 at 11:44:47AM +0200, Olaf Kirch via RT wrote:
viega> >
viega> > Hi all,
viega> >
viega> > yesterday I came across a bug in OpenSSL 0.9.7-beta3. When getting
viega> > an EVP_CIPHER in OFB/CFB mode, it reports as its block size the
viega> > block size of the underlying encryption algorithm, rather than 1.
viega> > Needless to say, this makes any application fail that uses a
viega> > cipher in CFB/OFB stream mode.
viega> >
viega> > If this isn't a bug, it's at least a departure from the behavior
viega> > of previous versions... :)
viega> >
viega> > Looking at evp_locl.h, there are two monster macros for setting
viega> > up an EVP_CIPHER suite - the one that's commented out at the
viega> > moment seems to do the right thing.
viega> >
viega> > Cheers,
viega> > Olaf
viega> > --
viega> > Olaf Kirch | Anyone who has had to work with X.509 has probably
viega> > [EMAIL PROTECTED] | experienced what can best be described as
viega> > ---------------+ ISO water torture. -- Peter Gutmann
viega> >
viega> > ______________________________________________________________________
viega> > OpenSSL Project http://www.openssl.org
viega> > Development Mailing List [EMAIL PROTECTED]
viega> > Automated List Manager [EMAIL PROTECTED]
viega> ______________________________________________________________________
viega> OpenSSL Project http://www.openssl.org
viega> Development Mailing List [EMAIL PROTECTED]
viega> Automated List Manager [EMAIL PROTECTED]
viega>
PGP.sig
Description: PGP signature
