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