Re: [Cfrg] Attacker changing tag length in OCB

[Richard Barnes <[e-mail]>]

To be clear, I was not saying that we shouldn't change OCB.  Just that this
is not a new problem for AEAD, nor one that will go away if we fix OCB.

On Thursday, May 30, 2013, Blumenthal, Uri - 0558 - MITLL wrote:

> Kevin,
>
> You agree with Richard – and I agree with Rene and James. There's no
> reason not to introduce an extra bit of (maybe unnecessary?) protection, as
> justification "nobody could/would get this wrong" has failed many people
> many times.
> --
> Regards,
> Uri Blumenthal
>
> From: Rene Struik <[e-mail] <javascript:_e({}, 'cvml',
> '[e-mail]');>>
> Date: Thursday, May 30, 2013 15:59
> To: "Igoe, Kevin M." <[e-mail] <javascript:_e({}, 'cvml',
> '[e-mail]');>>
> Cc: "[e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>" <
> [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>>
> Subject: Re: [Cfrg] Attacker changing tag length in OCB
>
> Dear colleagues:
>
> The observation that some AEADs have the property that one can truncate
> the authentication tag without affecting AEAD unsecuring operations was
> brought up by Rogaway and Wagner in their 2003 "Critique on CCM" paper
> (Section 3.4). It is therefore kind of interesting to see that the same
> observation applies to the OCB mode.
>
> Whether or not it is good to build-in protection against poor policy
> choices and management thereof is a matter of taste. History suggests that
> lots of security vulnerabilities arise precisely because of these poor
> choices (or lack of knowledge of impact of policy on security services
> offered). One could shield against poor choices in various ways, e.g., by
> using as key k:=Hash(K, TagLength).
>
> Best regards, Rene
>
> Ref: CCM Mode Critique (Rogaway, Wagner,  IACR ePrint 2003-070)
> http://eprint.iacr.org/2003/070
>
> On 5/30/2013 3:21 PM, Igoe, Kevin M. wrote:
>
> I agree with Richard.  The implicit assumption is that the length of the
> authentication tag has either been****
>
> agreed upon during the handshake or was a previously agreed upon
> parameter.  If you change the length****
>
> of the authentication tag in the live traffic, it almost certainly won’t
> pass authentication tag verification****
>
> by the intended recipient.  Offhand, I don’t see a security problem here.*
> ***
>
> ** **
>
> ** **
>
> *From:*[e-mail] [mailto:[e-mail]] *On Behalf Of
> *Richard Barnes
> *Sent:* Wednesday, May 29, 2013 11:45 AM
> *To:* Manger, James H
> *Cc:* [e-mail]
> *Subject:* Re: [Cfrg] Attacker changing tag length in OCB****
>
> ** **
>
> James,****
>
> ** **
>
> Don't most current AEAD modes have this property?  Namely, that there's no
> protection on the length of the authentication tag.  Off the top of my
> head, it seems that GCM, CCM, and SIV all have this property.****
>
> ** **
>
> So while it might be nice for OCB to fix this issue, implementations
> processing AEAD messages will still have to enforce minimum tag lengths on
> their own.****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> On Tue, May 28, 2013 at 8:47 PM, Manger, James H <
> [e-mail]> wrote:****
>
> >       Title           : The OCB Authenticated-Encryption Algorithm
> >       Filename        : draft-irtf-cfrg-ocb-02.txt
> > http://tools.ietf.org/html/draft-irtf-cfrg-ocb-02
>
> OCB with tag lengths of 64, 96, and 128 bits are defined. 64-bit and
> 96-bit tags are simply truncated 128-bit tags. The tag length is not mixed
> into the ciphertext. It never affects any input to an AES operation.
>
> Consequently, given a valid output from the AEAD_AES_128_OCB_TAGLEN128
> algorithm it is trivial to produce a valid output from the
> AEAD_AES_128_OCB_TAGLEN64 algorithm -- just drop the last 8 bytes.
>
> Is this ok?
>
> Another consequence is that an attacker wanting to change the additional
> data (eg from saying "TOP SECRET" to "PUBLIC") while keeping the same
> plaintext only has to defeat the shortest tag a recipient accepts,
> regardless of the tag applied by the originator.
>
> Is this ok? It doesn’t feel ok.
>
> Of course if a recipient accepts 64-bit tags an attacker can forge
> messages with a probability of 2^-64. However, that doesn’t seem to be
> exactly the same as forging a message with the same plaintext as a message
> originally authenticated with a 128-bit tag.
>
> Would OCB be better if the algorithms with different tag lengths couldn’t
> affect each other? Perhaps restricting the nonce to <126 bits (instead of
> <128 bits) and encoding the tag length in 2 bits.
>
> --
> James Manger
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg****<
>
> _______________________________________________
> Cfrg mailing [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> --
> email: [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');> | Skype: rstruik
> cell: [phone] | US: [phone]
>
>