> I have a simple question: > > Currently EVP_Encrypt* interface doesnt support > encryption of multiple data streams with a single > symmetric key. Is there any chance patches to > allow this to be accepted in the official OpenSSL > codebase ? Currently I'm thinking to modify EVP_EncryptFinal > so it leaves the EVP_CIPHER_STATE in a consistent state > after finishing its work.
The EVP docs are not really really clear about what's the best way to encrypt multiple messages with the same key, however at least in 0.9.6 it is possible to reuse an EVP_CIPHER_CTX after EVP_CipherFinal by calling EVP_CipherInit on it again and saving the inefficiency of having to regenerate the key schedule for every message. In 0.9.7 this capability seems to be currently broken, because the Final routines now call EVP_CIPHER_CTX_cleanup which wipes out the context. In general, I would argue in favor of keeping the 0.9.6 EVP interface for compatibility. But I also think there's currently a bit of confusion in the EVP design because the EVP_CIPHER_CTX object holds both (a) the key schedule and (b) the Init/Update/Final context. In a lot of applications, you might want to use the same key to encrypt/decrypt multiple messages but carry forward the residual IV to hide patterns in the plaintext, and bundling (a) and (b) in the same object makes a clean implementation of this somewhat difficult. I would propose (if we're talking new API) that EVP_CIPHER_CTX continues to hold the key schedule but we make a new object such as EVP_CIPHER_MESSAGE_CTX which handles the message Init/Update/Final context. Then you could make one EVP_CIPHER_CTX to encapsulate the key schedule, and as many EVP_CIPHER_MESSAGE_CTX objects as you want (derived from the EVP_CIPHER_CTX), one for each of your multiple data streams. In this usage, the Init/Update/Final routines would keep their state in an EVP_CIPHER_MESSAGE_CTX. The EVP_CIPHER_MESSAGE_CTX would reference the master EVP_CIPHER_CTX object using a const pointer, so the Init/Update/Final routines would only read the master EVP_CIPHER_CTX, never modify it. And I would add an optional pointer to the Final routine to write the final IV somewhere. This all of course would need to be done in a new, but parallel API -- too many applications rely on the current API (I happen to maintain one of them) for us to consider superceding it this late in the game (my opinion). Comments? James Yonan OpenVPN developer http://openvpn.sourceforge.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
