How about adding a high-level function in 0.9.7 a la SHA1() and MD5(), for example EVP_Decode() and EVP_Encode()? I suspect that a majority if base 64 encodes/decodes are on a single chunk so the Init/Update/Final/defining EVP context mechanism is overkill at the app level. Chris Brook
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte via RT Sent: Thursday, August 15, 2002 5:15 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #223] Length error in EVP_DecodeBlock [[EMAIL PROTECTED] - Wed Aug 14 22:36:47 2002]: > EVP_DecodeBlock() [in crypto/evp/encode.c] returns the length of the > result > of the base-64 decode. However this length is not the true length of > the > result but includes any trailing fills ('=') so it's always 0 mod 3. > This > obviously can cause errors in any processing on the result, e.g. > decryption. > I would suggest that adding something like: > while (*--f == '=') > --ret; > immediately before the "return(ret);" would solve the problem. Well, depends. If you consider that EVP_DecodeBlock() really just is a helper function for EVP_DecodeUpdate(), the implementation is correct, and you're change would actually break EVP_DecodeUpdate() as well as any call to EVP_DecodeBlock() that expects the current behavior. You see, EVP_DecodeUpdate() checks for the final '=' and decreases the final length accordingly. You need to do the same. This ticket is resolved. -- Richard Levitte [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
