Add GCM, CTR, and CTS modes to AES.

nss/mozilla/security/nss/lib/freebl/ctr.h

+/* This Source Code Form is subject to the terms of the Mozilla Public
+ * License, v. 2.0. If a copy of the MPL was not distributed with this
+ * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
+/* $Id: gsm.c,v 1.27 2012/04/25 14:49:43 gerv%gerv.net Exp $ */
+
+#ifndef CTR_H
+#define CTR_H 1
+
+#include "blapii.h"
+
+struct CTRContextStr {
+   freeblCipherFunc cipher;
+   void *context;
+   unsigned char counter[MAX_BLOCK_SIZE];
+   unsigned char buffer[MAX_BLOCK_SIZE];
+   unsigned long counterBits;
+   unsigned int bufPtr;
+};

[Ryan Sleevi, 2012/09/11 19:34:30]

In the other headers, the relevant ContextStr is forward declared (such as on
line 20 in this file), but does not appear in the actual header.

It seems like this belongs within ctr.c instead

[rjrejyea, 2012/09/19 21:38:00]

In other headers, the structure can be opaque. In the GCM case, we include a
full CTR context in the GCM context, so the struct CTRContextStr needs to be in
header (since it's shared with gcm and ctr.

+
+typedef struct CTRContextStr CTRContext;
+
+SECStatus CTR_InitContext(CTRContext *ctr, void *context, 

[Ryan Sleevi, 2012/09/11 19:34:30]

nit: Does this need to be a public method? Are callers expected to call it? It
seems an internal implementation detail of how CTR_CreateContext performs work.

Compared with CTS_ and GCM_, which both lack InitContext functions, I had
trouble understanding the distinction and purpose, unless it's supposed to be an
optimization strategy (when combined with the public definition of
CTRContextStr)

[wtc, 2012/09/14 01:16:42]

Exactly. gcm.c also needs struct CTRContextStr and
CTR_InitContext to avoid a memory allocation.

(I also wondered about this.)

[rjrejyea, 2012/09/19 21:38:00]

Yup, same reason the context isn't opaque. GCM needs to call the init function.
This is similiar to the way the AES_Init function operates.

+                        freeblCipherFunc cipher, const unsigned char *param,

[Ryan Sleevi, 2012/09/11 19:34:30]

nit/non-functional: Why the use of "const unsigned char" vs "const void"? The
best I can come up with is that it may be somehow related to alignment and
de-referencing, but given its usage, it seems like "const void*" would be better
here and functionally equivalent.

[wtc, 2012/09/14 01:16:42]

The const unsigned char * type comes from the
const unsigned char *iv argument of AES_CreateContext.
The |iv| argument is now overloaded to mean |param| for
the new modes of operations.

I don't know whether we should change the type to
const void * or the concrete type, such as
const CK_AES_CTR_PARAMS *. I'll ask rrelyea.

[rjrejyea, 2012/09/19 21:38:00]

I was reluctant to change the signature of AES_CreateContext, since there are
some external users of the function, much as I have railed against such use.

+                        unsigned int blocksize);
+
+CTRContext * CTR_CreateContext(void *context, freeblCipherFunc cipher, 

[Ryan Sleevi, 2012/09/11 19:34:30]

It would be good to document what |context| is here (and on line 22), in that it
represents the inner cipher context to use with freeblCipherFunc

+                        const unsigned char *param, unsigned int blocksize);
+
+void CTR_DestroyContext(CTRContext *ctr, PRBool freeit);

[Ryan Sleevi, 2012/09/11 19:34:30]

It's worth noting that this function **does not** free the |context| supplied in
Create/InitCOntext (meaning that the context needs to remain valid for as long
as the CTRContext is valid)

+
+SECStatus CTR_Update(CTRContext *context, unsigned char *outbuf, 
+                        unsigned int *outlen, unsigned int maxout, 
+                        const unsigned char *inbuf, unsigned int inlen,
+                        unsigned int blocksize);
+
+#endif