[Cfrg] comments on draft-mcgrew-auth-enc-03.txt

[Phillip Rogaway <[e-mail]>]

Hi David,

  In an earlier email (6 Oct 2006) (cc'ed to the cfrg) I passed on some
  comments on draft-mcgrew-auth-enc-00.txt.  I've just taken a look at
  latest incantation, draft-mcgrew-auth-enc-03.txt (July 6, 2007), so
  thought to pass on some fresh comments.

  Since my comments are critical, I think I should say up front that
  I think the draft is greatly improved since the -00 version that I
  reviewed last year, and, also, that I think that an RFC along these
  lines might be valuable.


  1. Nonces and the specific AEAD goals you intend

  Your ID says that "Each nonce provided to distinct invocations
  of the Authenticated Encryption operation MUST be distinct,
  for any particular value of the key."  This statement stands in
  direct contradiction to your later statement that "The number of
  octets in the nonce MAY be zero".  (This latter statement is
  itself ambiguous, either asserting that a _given_ nonce may have
  zero bytes (N_MIN = 0), or that all nonces will (N_MAX = 0).)

  The requirement that a nonce never repeats precludes the possibility
  of an appropriately-long user-supplied random value. Say this explicitly
  if you really mean it.  But I myself would find this an odd choice; to me,
  a random nonce isn't just a _reasonable_ thing for the user to be able
  to supply, it's a _canonical_ thing to supply!  If you mean to
  prohibit the user from providing random nonces, I can only assume this
  is rooted in experience that this is something so easily messed up
  that users of a cryptographic interface must NOT be allowed to do it....

  In general, though, I find entire story on nonces, and how they relate
  to the cryptographic goal one is aiming for, to be kind of muddy.
  Eg., we are told that a probabilistic encryption scheme may use a
  zero-length nonce, but you don't say that a probabilistic scheme MUST
  use a zero-length nonce, nor do hint at what would be the intended
  cryptographic semantics when you have a nonce _and_ internal coins.
  We are not told that _only_ a probabilistic scheme may use a
  zero-length nonce and I cannot actually tell if you intend
  deterministic AE (key-wrap) to be in scope or not.  You make clear
  that a counter may be used as a nonce, but it's unclear if it may
  be used (instead of coins) internally to an encryption mechanism
  (perhaps creating the odd asymmetry that counters may be shipped in or
  generated internally, but random coins MUST be generated internally).
  Must an (internal) counter-based scheme have N_MAX=0 and, if not, what
  is the meaning of supplying a nonce when there is also internal
  state. And so forth ....

  Perhaps part of the problem is that there are multiple AEAD formulations
  in the literature, these corresponding to some genuine difference about
  concerning the use of coins and state in the encryption process and whether
  or not an external nonce is supplied:

         -----------------------------------------------------------------
         | Probabilistic| Stateful    | Nonce-based      | Deterministic |
         | AEAD  [BN00] | AEAD [BN00] | AEAD [RBBK01,R02]| AEAD   [RS06] |
         -----------------------------------------------------------------
  coins? |      yes     |     no      |       no         |     no        |
  state? |       no     |    yes      |       no         |     no        |
         -----------------------------------------------------------------
  nonce? |       no     |     no      |       yes        |     no        |
         -----------------------------------------------------------------

  You can't quite ignore these subtleties in your ID because (a) what
  the user supplies to the encryption and decryption algorithms vary;
  (b) what is allowed in the underlying encryption algorithms varies
  (in terms of maintaining state or using randomness);
  (c) some combinations either haven't been defined or don't seem to make
  a whole lot of sense; and
  (d) a user of the interface needs to make an informed decision about
  what service he wants.


  2. Mixing algorithms and interfaces, and SHOULD(|Nonce|=14)

  An interface definition ought aim to be mechanism-neutral.
  Indeed the high-level decision to specify in one ID both an
  interface and four particular algorithms feels kind of "political".

  One problem with mixing algorithms and an interface in one document
  is that it can lead one to favor the specified mechanisms (CCM and GCM)
  in somewhat hidden ways.  For example, you say that a nonce SHOULD
  be 12 octets, the (somewhat idiosyncratic) choice of CCM, GCM.  Why?
  The best reason I can think of for suggesting a particular nonce length
  would be the hope that a user could select this length and be sure that
  any mechanism conforming to all SHOULDs would support this choice. But if
  that's the goal you'd want to say   SHOULD (N_MIN <= 12 and N_MAX >= 12),
  not SHOULD (N_MIN = N_MAX = 12).   Still, even the relaxed SHOULD
  denigrates probabilistic, stateful, and deterministic encryption; perhaps
  one might say SHOULD ((N_MIN<=12 and N_MAX>=12)) OR (N_MIN=N_MAX=0)?
  But by that point it really seems better to remove any SHOULD about
  nonce lengths....


  3. Vector-value AD

  The ID says that the AD must be a string, but SIV mode, an AEAD scheme
  by Tom Shrimpton and me [RS06], uses a vector-valued AD.  Your own ID
  might itself be seen as having some contents that motivate a
  vector-valued AD, eg, when you indicate that the AD could include

     addresses, ports, sequence numbers, protocol version numbers,
     and other fields that indicate how the plaintext or ciphertext
     should be handled, forwarded, or processed. In many situations,
     it is desirable to authenticate these fields.

  Note the plural, "fields"; I think the AD is quite often a list
  of values (more often then is a plaintext, nonce, or key).
  If this list must be formed into a string by the user there is
  a conceptual gap, a specificational gap, and a lost opportunity
  for optimization.  See [RS06].

  I am not trying to suggest that it's a terrible a thing for the AD
  to be a string; indeed a string AD has a different kind of elegance
  on it side. I'm only saying that it might be nice not to _preclude_
  the AD from being a vector of strings.


  4. Unbounded strings and the constants P_MAX, A_MAX, and N_MAX

  I understand P_MAX, A_MAX, and N_MAX to be bounds on what the
  mechanism is algorithmically capable of handling. One might guess
  the "type" of these values to be nonnegative integers. But it's more
  like that or "infinity": some algorithms can handle strings of any
  length (and indeed this is generally desirable). Be sure to indicate
  that these values can be nonnegative integers OR infinity.


  5. Nomenclature

  Getting to some lower-level stuff, I'll repeat my suggestion that the
  term "additional authenticated data" and the acronym "AAD" be replaced
  by the term "associated data" and the acronym "AD". While I realize
  that there's some precedent for the term AAD, (a) the (relatively
  small amount of) scientific literature making mention of this concept
  seems to favor "associated data" (eg, compare google-scholar hits);
  (b) The phrase "additional authenticated data" makes no English-language
  sense: the data isn't authenticated, it's something the user _wants_ to
  have authenticated. (Calling it (additional) authenticated data is
  a bit like naming a plaintext a "jumbled string" because the user
  wants to encrypt it.) (c) you already use the term AEAD extensively,
  an acronym that stands for "authenticated encryption with associated
  data" -- not "authenticated encryption with additional authenticated data".

  I'll mention too that, given the centrality of AEAD to this document,
  you probably should reference [R02], where AEAD was first named, defined,
  and formally investigated.


  6. Questionable prose

  Finally, a few specific statements that didn't make a whole lot of
  sense to me and probably should be cut:

  a. "When [AD, A, is used], authentication is provided without
     copying the data [A] into the ciphertext."  Not formally
     meaningful, not something you're in any position to mandate, and
     not something anyone would even think to do! [Encode A in the
     plaintext, perhaps....]

  b. "The nonce MAY be included in P or A if it is convenient to
     the application."   An odd suggestion.  A user-supplied nonce is
     needed for decryption, so somehow encoding it into the plaintext
     would serve no ostensible purpose; regardless, a user doesn't
     need your blessing to put anything he wants into P. Similarly, it
     would be weird to put a nonce into A, since, as you point out,
     the nonce is already authenticated; but, regardless, this isn't for
     you to judge.  (Actually, the one thing a user actually SHOULDN'T
     drop into P or A -- the key K or something derived from
     it -- you're silent on.)

  c. "The authenticated decrypt operation will, with high probability,
     return FAIL whenever its inputs were not created by the encrypt
     operation with the identical key (assuming that the AEAD algorithm
     is secure)."  This sentence has two interpretations, the way I read
     it, one of which is incorrect: that the decryption of a ciphertext C
     under a key K' different from the encryption key K will usually
     result in FAIL. That reading makes sense, but the claim isn't implied
     by any standard notion of AE security.


  Best wishes,
  phil


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