Re: [Cfrg] new authenticated encryption draft

[[e-mail] (David Wagner)]

David A. McGrew wrote:
>Authenticated Encryption (draft-mcgrew-auth-enc-00.txt)

This looks like a useful document.  Thanks for putting this together.

Here are a slew of minor comments:

Saying that the IV is generated by the AEAD algorithm seems a little
unusual.  Many AEAD algorithms permit the application to provide a nonce
to the AEAD algorithm, which is used for encryption (and for decryption).

This might be more flexible, because it allows the nonce to be meaningful
to the application in some special cases.  For instance, you can use
nonce = sector number for disk encryption (well, not actually, because
disk encryption has to be length-preserving, but you get the idea).
It could also fit into your framework, as a case of an AEAD algorithm
where the IV is taken to be exactly the IV contribution, and where the
mode documents that IV contributions must not repeat.  Perhaps this is
what you are trying to address with your "IV contribution"?

I prefer to use the term "nonce" when the only requirement is that nonces
must not repeat.  I tend to use "IV" when there are stricter requirements
(such as that IVs be uniformly random and unpredictable).

You don't use the term "AEAD" consistently.  In one place, you say that
an AEAD algorithm has two operations, encryption and decryption.  In some
other places, you seem to use AEAD to refer solely to the encryption
operation, and AAD for the decryption operation.  Be consistent.  One
option is to always use AEAD vs AAD to refer to encryption vs decryption.
Alternatively, when you are referring to just the encryption operation,
use "AEAD encryption algorithm" instead of just "AEAD algorithm".
(For instance, when you say the IV is an output of the AEAD algorithm,
you might mean that it is an output of the AEAD encryption algorithm --
obviously, it is not an output of the decryption algorithm, but rather
an input).

By your definitions, no secure stateless AEAD algorithm can be
deterministic, because the IV has to have some randomness in it.
Did you perhaps mean that deterministic means the ciphertext output of
the encryption algorithm is a deterministic function of the inputs and
of the IV generated, or did you actually mean what you write?

I don't know why you require that the IV contribution be included
"verbatim" in the IV.  (I don't even know what the word "verbatim" means,
precisely.)  This seems like a peculiar requirement with no purpose that
I can discern.

Your document doesn't state any requirements on the IV contribution.
Therefore, you should say that the mode specification must specify any
requirements on the IV contribution (e.g., that it be non-repeating)
that an application is required to abide by.

I don't think it's wise to vary the length of the authentication tag
separately for each packet.  The tag length should be bound to the key
and should never change for the lifetime of the key.

I don't think you should be saying that the IV is authenticated internally
to the algorithm.  The receiver should only be looking at the decrypted
plaintext and the authenticated data; higher layers at the receiving
side should not be looking at the IV.  Thus, I'm not sure in what sense
one can say that the IV is authenticated.  Standard security definitions
promise nothing about that.  Moreover, you should not be promising that
the decryption operation will detect incorrect IV values, because that is
not necessarily guaranteed by standard security definitions (for instance,
imagine if the last bit of the IV is ignored by both the encryption and
decryption operation; then an attacker who flips that last bit while
the IV is in transit will go undetected, but no harm will be done).
It is, however, accurate to say that no security failure results when
the decryption operation is provided with an incorrect IV, as long as you
define "security failure" to mean that the decryption operation returns
some plaintext as valid (without FAILing) when that plaintext was never
processed by the encryption operation.

I think you mean the IV may be transported along with the ciphertext
(not "plaintext").  I think the sentence "The entire IV need not
be transmitted; it is sufficient to provide the receiver with enough
information to allow the IV to be reconstructed." is confusing.  You are
describing two algorithms.  It is enough to say that the IV output by
the encryption operation must be provided as input to the decryption
operation.  The question of how it is provided to the decryption
operation is up to the lower layers (or to the application, depending
on how you look at it), but that question is 'none of your business'
(i.e., it is irrelevant to an AEAD spec).

The first paragraph of Section 3 looks like a repeat of things already
stated earlier.  Skip it?

Is there any value in defining a generic composition, like
AEAD_AES_128_HMAC_SHA1, except that it uses AES-CMAC instead of SHA1-HMAC?
This would be for systems that have AES but don't want to implement SHA1
(e.g., embedded systems; hardware).

-- David

_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg