This is a discussion on Re: Add GCM Mode for AES-128 - Openssl ; 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 ...
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
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.
On 3/18/06, Aaron Christensen
> This is my first time posting to this list, so I apologize if I don't fol=
> any usual etiquette.
> I'm planning on adding the GCM mode of operation to OpenSSL as a project =
> 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 pu=
> any thought into implementing Authenticated Encryption with Associated Da=
> modes. In studying the OpenSSL crypto code it seems that this relatively
> new paradigm could be force-fit into the current implementation. It seem=
> 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 all=
> for unencrypted, though authenticated, data to be combined with encrypted
> data in the creation of a "tag", or MAC, as part of the encryption proces=
> 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
> 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 cod=
> and it's workings, though, so my thoughts may be somewhat naive. Here th=
> * 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 bri=
> the tag "uptodate" with the rest of the encryption and tag generation
> process. This seems kind of backwards, and doesn't allow for incremental=
> adding associated data. It may be functional, though...
> * Add a new set of EVP APIs for AEAD: For example, EVP_AEAD. A new set o=
> APIs could account for the additional Authenticated (but not encrypted) d=
> 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 co=
> 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 t=
> do something relatively quick (as the semester is about halfway over). I=
> like to continue working on this though if there is interest.
> ~Aaron Christensen
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com