Re: CFB change
Bruce Stephens wrote: Dr. Stephen Henson st...@openssl.org writes: [...] Didn't realise anyone was using CFB for that. Note - there is now a Debian bug logged too for encfs which appears to be impacted by this change. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571810 I've forwarded your email (SteveH) noting that you are reverting that change. Thanks, Tim. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CFB change (was Re: OpenSSL version 0.9.8m release)
With 0.9.8m I'm getting some failures to read PEM files (and do some other thnigs, I think) that 0.9.8l is happy with. The PEM files are created by BouncyCastle, I think (though I imagine 0.9.8l could be persuaded to write similarly failing files). they begin something like: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CFB,9ab9883444955f24fc4d9ac26efa955d They seem to be caused by this change, so what's the story behind it? i.e., how worried should I be that software's currently writing files that are rejected by the new code in OpenSSL? Author: steve steve Date: Mon Feb 15 19:40:45 2010 + The block length for CFB mode was incorrectly coded as 1 all the time. It should be the number of feedback bits expressed in bytes. For CFB1 mode set this to 1 by rounding up to the nearest multiple of 8. diff --git a/crypto/evp/evp_locl.h b/crypto/evp/evp_locl.h index ef6c432..72105b0 100644 --- a/crypto/evp/evp_locl.h +++ b/crypto/evp/evp_locl.h @@ -127,9 +127,9 @@ BLOCK_CIPHER_def1(cname, cbc, cbc, CBC, kstruct, nid, block_size, key_len, \ #define BLOCK_CIPHER_def_cfb(cname, kstruct, nid, key_len, \ iv_len, cbits, flags, init_key, cleanup, \ set_asn1, get_asn1, ctrl) \ -BLOCK_CIPHER_def1(cname, cfb##cbits, cfb##cbits, CFB, kstruct, nid, 1, \ - key_len, iv_len, flags, init_key, cleanup, set_asn1, \ - get_asn1, ctrl) +BLOCK_CIPHER_def1(cname, cfb##cbits, cfb##cbits, CFB, kstruct, nid, \ + (cbits + 7)/8, key_len, iv_len, \ + flags, init_key, cleanup, set_asn1, get_asn1, ctrl) #define BLOCK_CIPHER_def_ofb(cname, kstruct, nid, key_len, \ iv_len, cbits, flags, init_key, cleanup, \ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CFB change (was Re: OpenSSL version 0.9.8m release)
On Fri, Feb 26, 2010, Bruce Stephens wrote: With 0.9.8m I'm getting some failures to read PEM files (and do some other thnigs, I think) that 0.9.8l is happy with. The PEM files are created by BouncyCastle, I think (though I imagine 0.9.8l could be persuaded to write similarly failing files). they begin something like: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CFB,9ab9883444955f24fc4d9ac26efa955d They seem to be caused by this change, so what's the story behind it? i.e., how worried should I be that software's currently writing files that are rejected by the new code in OpenSSL? Author: steve steve Date: Mon Feb 15 19:40:45 2010 + The block length for CFB mode was incorrectly coded as 1 all the time. It should be the number of feedback bits expressed in bytes. For CFB1 mode set this to 1 by rounding up to the nearest multiple of 8. diff --git a/crypto/evp/evp_locl.h b/crypto/evp/evp_locl.h index ef6c432..72105b0 100644 --- a/crypto/evp/evp_locl.h +++ b/crypto/evp/evp_locl.h @@ -127,9 +127,9 @@ BLOCK_CIPHER_def1(cname, cbc, cbc, CBC, kstruct, nid, block_size, key_len, \ #define BLOCK_CIPHER_def_cfb(cname, kstruct, nid, key_len, \ iv_len, cbits, flags, init_key, cleanup, \ set_asn1, get_asn1, ctrl) \ -BLOCK_CIPHER_def1(cname, cfb##cbits, cfb##cbits, CFB, kstruct, nid, 1, \ - key_len, iv_len, flags, init_key, cleanup, set_asn1, \ - get_asn1, ctrl) +BLOCK_CIPHER_def1(cname, cfb##cbits, cfb##cbits, CFB, kstruct, nid, \ + (cbits + 7)/8, key_len, iv_len, \ + flags, init_key, cleanup, set_asn1, get_asn1, ctrl) #define BLOCK_CIPHER_def_ofb(cname, kstruct, nid, key_len, \ iv_len, cbits, flags, init_key, cleanup, \ Didn't realise anyone was using CFB for that. Is that some default or does it have to be specifically requested? I had been reading SP800-38a which says in 5.2: For the CFB mode, the total number of bits in the plaintext must be a multiple of a parameter, denoted s, that does not exceed the block size The parameter s is the number of feedback bits which would be 128 for CFB-128. The result of that change is to pad any incomplete final block using standard block padding rules. Though checking information in other places and looking at the algorithm this is clearly *not* a requirement because the last complete block can be used to produce a final incomplete block. I'll revert that change. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CFB change
Dr. Stephen Henson st...@openssl.org writes: [...] Didn't realise anyone was using CFB for that. Is that some default or does it have to be specifically requested? It was explicitly requested, though I'm not sure for any positive reason in this case (more because we'd used that cipher and mode elsewhere, I think). I don't have any reason to think it's a default anywhere (well, I know some Isode software uses it, but apart from us...). I had been reading SP800-38a which says in 5.2: For the CFB mode, the total number of bits in the plaintext must be a multiple of a parameter, denoted s, that does not exceed the block size The parameter s is the number of feedback bits which would be 128 for CFB-128. The result of that change is to pad any incomplete final block using standard block padding rules. Though checking information in other places and looking at the algorithm this is clearly *not* a requirement because the last complete block can be used to produce a final incomplete block. I'll revert that change. OK, thanks. That sounds reasonable behaviour, and might avoid problems with BouncyCastle (presuming they don't make a similar change, of course). [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org