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
