On Sat, Mar 18, 2006 at 01:15:29PM -0600, Aaron Christensen wrote:

> * Add a new set of EVP APIs for AEAD: For example, EVP_AEAD. A new set of
> APIs could account for the additional Authenticated (but not encrypted) data
> and the tag that results after finalization. To me this seems to be the
> intuitively correct design (or some form of this). It seems that this could
> have far ranging consequences (i.e. with engines at the very least).


It does make it easier to add other combined modes in the future, since
otherwise they would all have to replicate the same kludgy interface using
EVP_CIPHER_CTX_ctrl.

I'm not sure exactly how feasible this is with GCM specifically, but perhaps
you could define the implementation of GCM in terms of EVP_CIPHER? That would
get you support for bare AES hardware through the standard engine code, and you
could build on that. You wouldn't be able to support hardware that had specific
GCM support, but that would probably require fairly invasive changes to the
engine code, which would probably take up too much time. And so far I haven't
seen hardware that supported GCM anyway.

-Jack

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org