Add GCM Mode for AES-128

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Add GCM Mode for AES-128

Aaron Christensen
This is my first time posting to this list, so I apologize if I don't follow any usual etiquette.

I'm planning on adding the GCM mode of operation to OpenSSL as a project for a crypto class I'm taking.  I would like to, if is desirable, to give the work back to the OpenSSL project.  As such, I am curious if anyone has put any thought into implementing Authenticated Encryption with Associated Data modes.  In studying the OpenSSL crypto code it seems that this relatively new paradigm could be force-fit into the current implementation.  It seems that a new envelope paradigm may be more appropriate, though I don't know what the feelings are on this...

GCM is, and I apologize for repeating for those familiar, a mode that allows for unencrypted, though authenticated, data to be combined with encrypted data in the creation of a "tag", or MAC, as part of the encryption process.  The result is that it is not necessary to perform a seperate MAC after encryption.  It works much like counter mode, except that a unique GHASH incrementally constructs a tag as the ciphertext is being incrementally constructed.

Have there been any thoughts on how to add Authenticated Encryption with Associated Data (AEAD) modes?  I've thought of a few; I'm new to this code and it's workings, though, so my thoughts may be somewhat naive.  Here they are:

* Retrofit into the current EVP_CIPHER: Use the ctrl interface of the EVP_CIPHER struct to add authentication data and a buffer for holding it.  Upon first encryption, the aes_128_gcm function would process this to bring the tag "uptodate" with the rest of the encryption and tag generation process.  This seems kind of backwards, and doesn't allow for incrementally adding associated data.  It may be functional, though...

* 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).

So, are there thoughts, opinions, or criticisms on these ideas?  Other ideas?  I'm sure there are better ways to do this in OpenSSL.  I'd like to do something relatively quick (as the semester is about halfway over).  I'd like to continue working on this though if there is interest.

Thanks!
~Aaron Christensen
Reply | Threaded
Open this post in threaded view
|

Re: Add GCM Mode for AES-128

Kyle Hamilton
Is there a paper that describes this concept more fully?  I must admit
that I'm unfamiliar.

The problem with force-fitting it into the current implementation is
that new ciphers in SSL/TLS can only be added by IETF action.  It
would be interesting to have a sample of it, sure, but the tag would
have to be something like "RSA-GCMAES256-NULL", which would otherwise
appear to have no message integrity.  (...at least to most
implementations, which view the authentication/bulk encryption/HMAC
pieces to be completely separate.)  In that case, implementing such a
cipher mode would run counter to the protocol that the TLS designers
created.

It would seem to me, though, that the appropriate place for the GCM
MAC verification code would be as a set of callbacks in the HMAC
processing area.  (This could be something like RSA-GCMAES256-GCM,
which would make explicit that there is an HMAC-alike in place but
it's not SHA1 or MD5 -- and which would allow for implementations to
have such a callback.)

However, the best place to bring this topic up would definitely be the
TLS working group.  That body is the one which controls the
specification, and the current TLS protocol doesn't have any place for
such unencrypted data -- it assumes that all data transmitted is going
to be through a fully-encrypted channel.  (which was its original
purpose, actually.)  The question is likely to be, "how would this add
value to the protocol?"

I don't mean to discourage you (and I'm by no means a project
developer); I'm expressing what I believe to be the issues that need
to be addressed.

On the flip side, though, I think I would very much like to know about
these modes as I can see specific instances in my own work where
they'd be useful.

Cheers,

-Kyle H



On 3/18/06, Aaron Christensen <[hidden email]> wrote:

> This is my first time posting to this list, so I apologize if I don't follow
> any usual etiquette.
>
> I'm planning on adding the GCM mode of operation to OpenSSL as a project for
> a crypto class I'm taking.  I would like to, if is desirable, to give the
> work back to the OpenSSL project.  As such, I am curious if anyone has put
> any thought into implementing Authenticated Encryption with Associated Data
> modes.  In studying the OpenSSL crypto code it seems that this relatively
> new paradigm could be force-fit into the current implementation.  It seems
> that a new envelope paradigm may be more appropriate, though I don't know
> what the feelings are on this...
>
> GCM is, and I apologize for repeating for those familiar, a mode that allows
> for unencrypted, though authenticated, data to be combined with encrypted
> data in the creation of a "tag", or MAC, as part of the encryption process.
> The result is that it is not necessary to perform a seperate MAC after
> encryption.  It works much like counter mode, except that a unique GHASH
> incrementally constructs a tag as the ciphertext is being incrementally
> constructed.
>
> Have there been any thoughts on how to add Authenticated Encryption with
> Associated Data (AEAD) modes?  I've thought of a few; I'm new to this code
> and it's workings, though, so my thoughts may be somewhat naive.  Here they
> are:
>
> * Retrofit into the current EVP_CIPHER: Use the ctrl interface of the
> EVP_CIPHER struct to add authentication data and a buffer for holding it.
> Upon first encryption, the aes_128_gcm function would process this to bring
> the tag "uptodate" with the rest of the encryption and tag generation
> process.  This seems kind of backwards, and doesn't allow for incrementally
> adding associated data.  It may be functional, though...
>
> * 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).
>
> So, are there thoughts, opinions, or criticisms on these ideas?  Other
> ideas?  I'm sure there are better ways to do this in OpenSSL.  I'd like to
> do something relatively quick (as the semester is about halfway over).  I'd
> like to continue working on this though if there is interest.
>
> Thanks!
> ~Aaron Christensen
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Add GCM Mode for AES-128

Jack Lloyd
In reply to this post by Aaron Christensen
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                       [hidden email]
Automated List Manager                           [hidden email]