An Interface and Algorithms for Authenticated Encryption
draft-mcgrew-auth-enc-05

Question: This is fairly abstract.  Will we be seeing more concrete
realizations of this idea in, for example, a PKCS #11 extension or
Java/C API bindings?  Or is this something that crypto or security
service libraries worry about and applications should ignore?

Is there going to be a mailing list set up where people can _optionally_
get advice to refine their registration?  (Mandatory list review is
annoying, but optional list review is often helpful).  I'm wondering
if IANA will have a problem with this registry given this text:
  "The current specification requires that a registered algorithm
   provide a complete specification and a set of validation data; it is
   hoped that these prerequisites set the admission criteria
   appropriately."
That sounds like you need an expert reviewer to verify that criteria
is met.

Editorial nits:
> none that only encryption is random, and decryption is alwasy
s/none/note/, s/alwasy/always/

> it MUST specify the number of octets in the largeset possible
s/largeset/largest/

> rollback; threats and mitigations of are an area of active research.
s/of are/in that scenario are/
> SHOULD use a nonce length of 12 octets, since with GCM is there is
s/is there is/there is/

> Directly testing a randomized AEAD encryption algorithm using a test
s/a test/test/

This is excellent work.


Section 4 discusses an IV, where I think it means to discuss a nonce
in a couple places.



Section 5.1.1 implies that encrypting the same plaintext twice with
AES GCM is problematic.  It needs to make it more clear that this is
in the context of nonce reuse.










I'm a bit concerned that because of the variable size of nonces and
because of the wide variety of nonce sizes that might be used this
will be hard to use as a framework.  I think if I were an application
designer trying to use this as an abstract interface I'd first try a
12-byte nonce, then try some nonce size specific to my application,
then try 0 byte nonce (to catch purely randomized algorithms) then
give up.  It would be nice if in addition to having a minimum and
maximum nonce size there was a preferred nonce size.