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.
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]
