Re: AES-CMAC - MAC lengths other than 128

On Fri, Feb 21, 2014 at 10:47 AM, Ryan Sleevi <sleevi@google.com> wrote:

>
> On Feb 21, 2014 7:25 AM, "Richard Barnes" <rlb@ipv.sx> wrote:
> >
> > For generation: Can't the JS truncate the MAC after it gets the full
> result back?
> >
> > For verification: I'm wary of having the API accept arbitrarily short
> MACs.  You would need to specify acceptable lengths in order to avoid
> things like an 8-bit MAC being accepted.  Is there standard practice /
> documentation for these lengths?
> >
>
> Richard,
>
> Is this the same concern you express regarding defaults? That is, that you
> want the API to be more high-level than it is?
>
> I didn't mean it that way, but rather as trying to keep tag lengths out of
the API.


> We already support arbitrary GCM tag lengths, I'm inclined to agree with
> Jim that we should keep parity with that (and HMAC).
>
My concern is really just about the semantics of "verify" being clear,
which would apply equally well to GCM ("decrypt").  If we're going to allow
arbitrary tag lengths, then we should probably put a note in the security
considerations that developers need to check that the tags are sufficiently
long.


> Disallowing this just encourages developers to do truncation and
> verification themselves, in non-constant time.
>
Truncation doesn't seem like a risk, but I can see your point w.r.t.
verification.

Could we set a minimum tag length, say 64 bits?  Is there really a use case
below that?

--Richard


>
> > On Thu, Feb 20, 2014 at 10:55 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
> >>
> >> Starting with the editorial note in section 18.12.1 - I would be  a
> strong advocate that MAC lengths other than 128 should be supported by the
> algorithm.  There is a section of the security community (no comment as it
> the correctness of its view) that states that security is increased by
> truncating the MAC from 128 to 96 bits.  This is a feature that people will
> want supported.
> >>
> >>
> >>
> >> Jim
> >>
> >>
> >
> >
>