------=_Part_4775_16461660.1142709329448
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is my first time posting to this list, so I apologize if I don't follo=
w
any usual etiquette.

I'm planning on adding the GCM mode of operation to OpenSSL as a project fo=
r
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 allow=
s
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) dat=
a
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 coul=
d
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

------=_Part_4775_16461660.1142709329448
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is my first time posting to this list, so I apologize if I don't follo=
w any usual etiquette.

I'm planning on adding the GCM mode of operat=
ion to OpenSSL as a project for a crypto class I'm taking.  I would li=
ke 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 Auth=
enticated Encryption with Associated Data modes.  In studying the Open=
SSL crypto code it seems that this relatively new paradigm could be force-f=
it into the current implementation.  It seems that a new envelope para=
digm 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 th=
at allows for unencrypted, though authenticated, data to be combined with e=
ncrypted 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, ex=
cept that a unique GHASH incrementally constructs a tag as the ciphertext i=
s 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 t=
he 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 t=
ag generation process.  This seems kind of backwards, and doesn't allo=
w for incrementally adding associated data.  It may be functional, tho=
ugh...


* 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 e=
ncrypted) data and the tag that results after finalization.  To me thi=
s 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, opinio=
ns, or criticisms on these ideas?  Other ideas?  I'm sure there a=
re better ways to do this in OpenSSL.  I'd like to do something relati=
vely quick (as the semester is about halfway over).  I'd like to conti=
nue working on this though if there is interest.


Thanks!
~Aaron Christensen


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