On Wed, Mar 03, 2010, PMHager wrote: > > > I don't see why the existing EVP_CIPHER interface isn't suitable. You add a > > new flag for GCM/CCM mode and pass or retrieve additional information via > > standardized ctrls. > > The difficulties I see are the restricted parameters at EVP_CipherInit_ex(), > EVP_CipherUpdate(), and EVP_CipherFinal_ex(). > > For the GCM (and other AEAD modes) the EVP_CipherInit_ex() would require an > additional iv-length parameter. Besides the EVP_CipherUpdate(), an extra > function for EVP_AadUpdate() (same syntax as HMAC_Update) will be necessary, > and the EVP_CipherFinal_ex() will require extra parameters for *md and its > length (similar to HMAC_Final 2nd&3rd parameter). Alternatively *outm and > *outl of EVP_CipherFinal_ex() could be "abused" to give the digest back. >
Well Aad could be handled by calling CipherUpdate with a NULL output buffer but I'd regard that as abusing the API somewhat. I don't think we should call EVP_CipherFinal_ex() to get the mac/digest back because although the proposed algorithms don't require padding a future one might. Better to have a ctrl to do that after EVP_CipherFinal_ex(). I'm thinking here that we should have a standardised technique for handling encrypt+mac which will also cover possible future needs. > Putting an EVP_AadUpdate() function into EVP_CIPHER_CTX_ctrl(), would mean > that the base functionality of the GCM will not available without using the > ctrl, which would make the GMAC and GCM uncomfortable to use. > Well we can add wrapper functions for the ctrl in OpenSSL so the actual ctrl is only exposed at the EVP_CIPHER level. We already have cipher specific parameter setting ctrls so this isn't that much of a change. > > If you add a whole new API you end up needing new algorithm tables, new > > ENGINE > > functions, new BIOs etc. > > The reason for my idea of an AEAD was just to keep the list of algo - mode > combinations small. (Engines could still be used by the internal calling of > the CTR algorithm.) But if this is not an issue, adding an EVP_AadUpdate() > at least would be fine. > I can see that we might in future require a complete replacement of the (for example) GCM algorithm by an ENGINE and not just the underlying EVP_CIPHER. It might (for example) provide a much faster accelerated version or one that is FIPS 140-2 compliant and then we would have to use the ENGINE version in its entirety. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
